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(54) Title: SYSTEM, METHOD AND COMPUTER PROGRAM PRODUCT FOR ONLINE FINANCIAL PRODUCTS TRADING 
(57) Abstract 

A system, method and computer 
program product are provided for an on- 
line, centralized financial products ex- 
change system which automates and stan- 
dardizes the secondary market process by 
applying a data transformation and map- 
ping process to loan information and in- 
stantly matching available loans and loan 
pools with the purchasing criteria of buy- 
ers. The system transforms the loan infor- 
mation that is entered by the user into a 
standardized data format. Data is filtered 
before being forwarded to a subscriber us- 
ing a pre-defined criteria selected by the 
subscriber. The system includes a plu- 
rality of Web servers for receiving and 
providing loan information from and to 
subscribers on several Web clients and a 
database server for searching the prede- 
fined rules to match potential buyers with 
sellers. The system also includes a data- 
base for storing information relating to ne- 
gotiations (i.e., bidding) for the sale of 
loans and for storing predefined rules for 
pre-registered buyers and sellers. The sys- 
tem further includes a database and server 
for storing risk/return information that is 
made available to subscribers for analysis. 
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System, Method and Computer Program Product for 
Online Financial Products Trading 



Background of the Invention 



Field of the Invention 

The present invention relates generally to a centralized exchange system 
for creating a marketplace to buy and sell financial products, and more particularly 
to a centralized exchange system for the trading of loans. 

Related Art 

Over the past several years, there has been an explosion of computers, and 
thus people, connected to the global Internet and the World-Wide Web (WWW). 
This increase of connectivity has allowed computer users to access various types 
of information, disseminate information, and be exposed to electronic commerce 
activities, all with a great degree of freedom. Electronic commerce includes large 
corporations, small businesses, individual entrepreneurs, organizations, and the 
like, who offer their information, products, and/or services to people all over the 
world via the Internet. 

Financial products are one of the types of products available through 
electronic commerce activities. Consumer loan products, one example of financial 
products available through electronic commerce, are typically divided into two 
categories—conforming (or conventional) loans and non-conforming (or non- 
conventional) loans. Conforming loans are low risk loans and include traditional 
primary residence mortgage loans to consumers with good credit histories and 
loans to consumers who qualify under certain government-backed loan programs 
(e.g., Federal Housing Administration (FHA) or the Veterans Administration 



In contrast to conforming loans, non-conforming loans pose a higher risk 
for lenders than conforming loans. Non-conforming loans include loans to 



(VA)). 
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consumers with bad credit (e.g., due to bankruptcy or foreclosure), non-income 
verification loans (e.g., loans to consumers who have been self-employed for less 
than 2 years), loans for non-owner occupied properties, loans for non- 
conventional properties, some commercial (business) loans, and High-Loan-To- 
Value (HLTV) loans. Generally, non-conforming loans are loans that do not meet 
the underwriting guidelines of Fannie Mae or Freddie Mac. 

For example, HLTV loans are typically obtained by consumers, who by 
using equity in their homes as collateral, consolidate other (e.g., credit card) debt. 
These types of loans involve a lender who loans a consumer an amount of money 
in excess of 100% of the consumer's equity in their home. For example, an 
"HLTV 125" loan refers to consumer who obtains a loan for 125% of the value 
of their home. 

In more detail, an "HTLV 125" loan would work as follows. A consumer 
who owns a home valued at $100,000, and has a first mortgage on that home for 
80% of the value (i.e., $80,000), would have 520,000 in equity. If the consumer 
has credit card debts and wanted to borrow money to consolidate these debts, a 
lender may offer the consumer an HLTV loan. In one scenario, the consumer may 
be able to obtain a loan for the 520,000 equity in their home, and borrow against 
an additional 25% of the value of the home (i.e., another $25,000) for a total loan 
of $45,000. As such, there would now be loans covering 125% of the value of the 
consumer's home. 

Under the current tax laws, this type of loan provides the consumer (i.e., 
borrower) with a tax advantage because a certain amount of the interest paid on 
this loan can be deducted on the borrower's income tax returns. In contrast, any 
interest paid on credit card debt cannot be deducted. Further, the interest rate that 
a borrower may be able to obtain for an HLTV loan is often less than the interest 
rate charged by most credit card companies, but amortized over a longer period 
of time. Thus, consolidating by obtaining an HTLV loan, lowers the borrower's 
monthly payments and allows the borrower to repay debts owed more quickly. 
As such, these types of loans are often attractive to consumers. 
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Non-conforming loans generally are also attractive to lenders because the 
market will often allow lenders to charge a higher interest rate than on a 
conventional first mortgage loan (although this interests rate is still lower than that 
charged by credit card companies). Because lenders are offering the borrower a 
loan for more than the value of the collateral (e.g., the borrower's home), 
however, there is a certain amount of risk involved in making such loans. As 
such, lenders have developed certain rules (based on criteria, such as underwriting 
criteria) to minimize their risks (i.e., exposure) when making non-conforming 
loans. 

An example criteria used by lenders include identifying potential borrowers 
in a certain income bracket. This income bracket must be high enough so that 
there is small likelihood of default, but not so high that the borrower is likely to 
prepay the loan-thereby decreasing the amount of interest collected by the lender 
over the life of the loan. 

Another criteria often considered by lenders making loans is the 
borrower's credit rating. A consumer's credit rating is an indication of their 
ability to pay outstanding debts. Credit rating companies, such as Trans Union 
Corporation of Chicago, Illinois, Experian, Inc. (formerly TRW) of Orange, 
California, and Equifax, Inc. of Atlanta, Georgia, collect certain information on 
individual consumers and assign each a credit rating based on this information. 

One method of obtaining a credit rating is known as a "FICO score" which 
is based on a mathematical model developed by Fair, Isaac, and Company, Inc. of 
San Rafael, California. A FICO score is based on many factors including how a 
consumer pays their bills, outstanding debt, how long a consumer has had credit, 
types of credit a consumer has, and how many times a consumer has recently 
applied for or opened new lines of credit. 

Borrowers are typically graded according to their borrowing habits. "A" 
borrowers have credit ratings which indicate that they will be able to repay a loan. 
The ratings given to borrowers fluctuate between institutions, with each institution 
defining loan borrowing criteria a little differently. For example, instead of just 
an "A" borrower, an institution may have an A- or B+ category for borrowers. 



WO 00/39736 



PCT/US99/31107 



-4- 

Loans can also be extended to "sub-prime" borrowers- individuals with 
U B" or "C" credit ratings. These subprime borrowers have relatively lower credit 
scores. Loans in this case may be the borrower's first mortgage on a home, e.g., 
for which the borrower has a risky credit rating, but they have collateral, such as 
a home, which has not been previously mortgaged. Similarly, loans can also be 
extended to borrowers who are seeking a "jumbo" Ioan~a loan of $225,000 or 
more. All of these types of loans, because of the various risks associated with 
each, often command a higher interest rate than conforming loans. 

Loan Life Cycle 

Referring to FIG. I, a time line of a typical loan life cycle 100 is shown. 
The first phase in the loan life cycle 100 is a marketing phase 104. In marketing 
phase 104, marketing companies target certain potential borrowers to receive 
advertisements offering loans. For example, potential borrowers may be targeted 
by geographic region (e.g., by zip code or area code). This advertising can be 
distributed through many sources, such as via telephone advertising campaigns, 
via mass mailings, or via the Internet. 

The second phase in the loan life cycle 1 00 is a loan origination phase 1 08. 
In loan origination phase 108, the potential borrower contacts the lender (e.g., 
mortgage bank), or a broker working with a lender, by phone or electronic mail, 
to request a loan. Usually, this first contact between the potential borrower and 
the lender is telephonic, as call centers are typically set up to handle responses to 
the advertising campaigns. After being switched away from the call intake portion 
of the call center, certain information is collected from the consumer by a loan 
agent. The loan agent also works with the potential borrower to agree on a loan 
amount, interest, points, duration or term of the loan and other features of the 
loan. The loan agent then sends this information to a loan processor and a loan 
underwriter for approval. 

The loan processor processes the paperwork necessary for completing the 
loan and the underwriter makes sure the underwriting guidelines are met. During 
the underwriting process, the underwriter decides whether to make a loan to a 
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potential borrower based on credit, employment, assets and other factors and then 
matches the risk of making such a loan to an appropriate rate and term or loan 
amount. Underwriting guidelines are the rules that the underwriters use to assign 
risk to a particular loan and to determine whether or not to approve the loan for 
a particular rate, term and loan amount. As such, the underwriter validates the 
interest rate and points assigned by the loan agent. If these validated terms are 
acceptable to both the lender and borrower, the loan is approved, and the loan 
agent then works with the loan closer to finalize the loan, issue a check, and 
forward it to the borrower. 

The loan may then enter a third phase, known as a loan wholesaling phase 
112. Once the lender has made the loan, they often try to sell the loan to 
investors, e.g., mortgage bankers, insurance companies, institutional investors, 
etc. Alternatively, a loan may be transferred within a company to a different 
department that handles the wholesaling of loans. Lenders may flow loans to 
mortgage bankers (i.e., pass a single loan at a time), or send bulk loans to 
mortgage bankers (i.e., pass several loans referred to as a "pool" of loans). The 
mortgage banker then separately pools the purchased loans and advertises the loan 
pools to look for investors. The role of the mortgage banker is to buy loans from 
the loan origination organization (e.g., mortgage bank) or lender, and then pool 
them in such a way to make them attractive to investors. 

Mortgage bankers have also developed rules that they use to decide which 
loans to purchase and how to pool them for sale. These rules are based on many 
of the same criteria used by the lender in determining whether to originate a loan 
to the borrower. Similarly, loan origination organizations or lenders consider the 
rules of the mortgage bankers when making loans, so that their loans look 
attractive to the mortgage bankers. 

The mortgage banker pools the loans and advertises to investors who may 
be interested in purchasing a pool of loans. For example, a typical pool may 
consist of 300 loans with an estimated total value of $30 million or may consist 
of 3000 loans with an estimated total value of $300 million. The potential 
investor, typically a bank, securitization company or another mortgage banker, 
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will review the information for each loan in the pool and either accept, decline, or 
reserve its decision for each loan in the pool. Then, the investor may send a 
revised pool back to the mortgage banker with an offering price to buy the revised 
pool. The mortgage banker then may add other loans to the pool and resend the 
pool to the investor for review. This negotiation (or bidding) continues until a sale 
is made or rejected. The rejected loans may be used in other pools or may be used 
directly for securitization, as discussed below. 

Once an investor purchases or otherwise acquires a pool of loans, the 
loans may enter a fourth phase, referred to as a securitization phase 116. In 
securitization phase 1 16, the investor groups several pools of loans together into 
a larger pool and uses them collectively as collateral to back securities (i.e., 
mortgage-backed securities such as bonds). These larger pools can then be 
offered for sale to buyers on the secondary market. Typically, these groups of 
loan pools are valued in the range of $50 million - $1 billion. Because the 
company that purchases the loan pools and uses them to back securities is 
personally responsible, there is a great deal of risk involved in these type of 
transactions. 

Naturally, investors of the loan pools have developed certain rules for 
evaluating the suitability of the loans for securitization. However, the mortgage 
bankers' rules used for grouping certain loans together in a pool may be different 
from the rules used by the investor in deciding which loans it would like to 
purchase in a pool and the rules used by lenders in making the underlying loans in 
the first place. For example, the mortgage banker in an attempt to sell the low 
risk and high risk loans together, may want to group together loans made to 
borrowers with high FICO scores with loans made to borrowers with lower FICO 
scores. However, the investor may have rules which do not allow the purchase 
of any pool with a loan made to a borrower having a FICO score less than a 
predetermined amount. As a result, negotiations between the mortgage banker 
and the investor must occur in order to decide on a pool and a price that is 
suitable to both parties. It is important to note that although the rules are devised 
as guidelines for buying and selling loans, these rules may be disregarded or 
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altered on a case-by-case basis. Further, each entity described above may 
frequently change its rules based on market conditions and other relevant factors. 

The process for selling loans or loan pools and then negotiating about the 
sale is currently ad hoc. Generally, an investor will learn about a pool by calling 
a particular seller to see what loans or loan pools are available. The seller will 
then send the investor information about the loan or loan pool generally on a 
spreadsheet, such as Microsoft® Excel. The investor may reconfigure the 
information into their preferred format on the spreadsheet, delete or mark those 
loans from the pool that they do not wish to purchase, and send the spreadsheet 
with the revised pool back to the seller. This process is often clumsy and 
inefficient, requiring a lot of manual data re-entry between the parties. 

Further, there is no mechanism, apart from person-to-person (e.g., face-to- 
face or over the telephone) interaction, for determining what loans or pools are 
for sale, what rules are being used to pool the loans, and what rules are being used 
by the investors to determine whether to buy certain loans. The tools that are 
available, such as program sheets or rate matrices, are not dynamic, i.e., they are 
not updated in real-time to reflect current market conditions. Instead, the existing 
tools are all static as they are typically updated through a manual process. 

The investors service the loans, either themselves or through a separate 
servicing firm, and create a mortgage-backed security based on the assets (i.e., 
future income stream) of the pooled loans. The mortgage-backed security has an 
assigned interest rate based on the future capital of the pools of loans that are 
being securitized. The mortgage-backed securities are then generally sold, either 
directly or through brokerage companies, to buyers in the open market. It is 
important to note that the servicing rights to these loans can be sold separately 
from the loans. In short, the seller may be marketing to two buyers: one for the 
loans and one for the servicing rights to the loans. 

The mortgage-backed securities are always securitized by the pool of 
loans, so that the loans can never be transferred again throughout the remainder 
of their life cycle 100. Prepayment of loans is a problem, because if a loan is 
prepaid the mortgage-backed security is no longer backed by all of its original 
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underlying assets. Companies that securitize these loans have attempted to predict 
the amount of prepayment of loans in the pools and work this figure into a yield, 
however many companies have failed because they could not accurately predict 
the rate of prepayment or default. 

The loan also follows a separate track with the consumer, concurrently 
with the first track described above. As shown in FIG. 1, once the loan is 
approved and the money is sent to the borrower, the loan enters a servicing phase 
1 20. Servicing phase 120 consists of a servicing company sending a coupon book 
or monthly notice to the borrower which indicates when monthly payments are 
due and the amount of the payment. If the borrower is iate on a payment, the 
servicer will contact the borrower to discuss the missed or late payment. This 
servicing is very methodical, in that servicing companies will often have predefined 
time periods for certain actions. For example, the servicing company may place 
a telephone call to a delinquent borrower after his payment is 10 days late, and 
write a letter to the delinquent borrower after his payment is 30 days late, and so 
on. 

If the borrower becomes insolvent or delinquent in their payments, the 
loan enters the next phase, referred to as a claims phase 124. In claims phase 124 
the servicing company may enter a claim against the borrower in a bankruptcy 
proceeding, or file a lawsuit in court to foreclose on the mortgaged property or 
secure an order to garnish the borrower's wages. When the value of the loan is 
greater than the value of the underlying collateral, lenders are reluctant to enter 
this phase, because it generally results in the lender losing money. In particular, 
when one of these loans is used to back a security, and the borrower defaults on 
the loan, the collateral used to back the security disappears. This has, in the past, 
lead to the demise of many securitization companies that back securities with such 
loans. 

On both tracks, the loan then enters a final phase, referred to as a loan 
termination phase 128. Generally the loan enters loan termination phase 128 when 
the loan has been fully paid, be it at the end of the loan term (e.g., 30 year fixed 
loan) or earlier (i.e., prepayment). 
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Therefore, in view of the above, what is needed is a system, method and 
computer program product for an online (i.e., Internet, Intranet, or Extranet) 
system for buying and selling financial products. Such a system would create a 
"marketplace" in which investors (i.e., buyers) and sellers of these financial 
products could go to place their products for sale, to ascertain what financial 
products are for sale, and to determine what the price is in the "marketplace" for 
certain types of products. Further, what is needed is a system, method and 
computer program product that archives all of the loan information and selection 
and pricing information for access by its users in a standardized format. 

Summary of the Invention 

The present invention is a system, method, and computer program product 
for the online trading of financial products. The present invention is optimized to 
handle fixed, adjustable, and balloon mortgages as well as first lien (sub-prime, 
jumbo, conforming) and second lien (sub-prime, home equity, home non-equity, 
Title I) products. Additional information, such as whether a loan has mortgage 
insurance or whether an applicant or census tract on which a piece of property is 
located qualify under the Community Reinvestment Act (CRA), will also be 
available for loans. In short, the invention automates and standardizes the 
secondary market process by instantly matching available loans and loan pools 
with the purchasing criteria of buyers. As such, the invention provides a resource 
of archived information for subscribers (e.g., marketing companies, lenders, 
mortgage bankers, investors, brokerage companies, etc.). In this way, every 
individual involved in the financial products industry can access information stored 
in the centralized "marketplace" system of the invention to aid in completing 
transactions relating to the financial products. 

The present invention further facilitates the passing of bulk and/or flow 
loans from a correspondent subscriber to a particular buyer pursuant to a 
correspondent delivery agreement. In particular, the system of the present 
invention receives the loan information from the subscriber and translates it into 
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a data format recognizable to the backoffice system of the particular buyer. The 
invention may also filter the loan information prior to sending it to the buyer using 
rules predefined by the buyer. The invention then send the loan information to the 
buyer's backoffice. 

The buyer can perform evaluations of the data, such as legal review and 
automated underwriting and then return a response to the seller via the system of 
the present invention as to whether the loan has been approved for purchase. 

In one embodiment, the loan data is transferred using an XML standard 
processing format. In another embodiment, the loan data is transferred from the 
seller's system in the seller's data format and mapped and translated to the 
standardized format. The subscriber may also access certain value added services 
via the system to aid in the purchasing decision. These value added services may 
include automated underwriting, automated pricing, rate locking, loan product 
comparison mapping, credit scoring, credit updates, CRA qualification, and 
appraisal updates. 

One advantage of the present invention is that it provides a centralized 
"marketplace" for trading in certain types of financial products. 

Another advantage of the present invention is that it reduces the amount 
of manual re-entry of data when negotiating for the sale of a financial product, 
such as a loan or loan pool. Furthermore, all data, including data relating to the 
financial product and trading data, are archived to allow for risk management 
analysis. 

Another advantage of the present invention is that it archives information 
about the financial products and bidding information to be used to determine a 
market price for the financial products. 

Another advantage of the present invention is that it archives rules which 
are predefined by investors and allows for dissemination of these rules so that 
originators are aware of what loans are in demand in the marketplace and 
originate the right types of loans, thereby creating an efficiency in loan origination 
and resale. 
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Further features and advantages of the invention as well as the structure 
and operation of various embodiments of the present invention are described in 
detail below with reference to the accompanying drawings. 

Brief Description of the Figures 

The features and advantages of the present invention will become more 
apparent from the detailed description set forth below when taken in conjunction 
with the drawings in which like reference numbers indicate identical or 
functionally similar elements. Additionally, the left-most digit of a reference 
number identifies the drawing in which the reference number first appears. 

FIG. 1 is a time line showing the typical life cycle of a loan; 

FIG. 2 is a block diagram illustrating the system architecture of a first 
embodiment of the invention, showing network connectivity among the various 
components; 

FIG. 3 is a high level block diagram showing the interfaces that occur 
during the operation of the exchange system according to the first embodiment of 
the invention; 

FIG. 4 is a block diagram illustrating the software architecture according 
to a first embodiment of the invention, showing communications among the 
various components; 

FIG. 5 is a flowchart showing the data flow between the centralized 
exchange system and a marketing company, according to the first embodiment of 
the invention; 

FIG. 6 is a flowchart showing the data flow between the centralized 
exchange system and a loan origination company, according to an embodiment of 
the invention; 

FIGS. 7-14 are exemplary graphical user interfaces according to a loan 
origination system of the invention; 
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FIGS. 15A-15D are flowcharts showing the buying and selling of loans 
using the centralized exchange system, according to the first embodiment of the 
invention; 

FIG. 16 is a flowchart showing the interaction between the centralized 
exchange system and a trust company, according to an embodiment of the 
invention; 

FIG. 17 is a flowchart showing the data flow between the centralized 
exchange system and a servicing company, according to an embodiment of the 
invention; 

FIGS. 18 and 19 are exemplary graphical user interfaces according to an 
embodiment of the invention; 

FIG. 20 is a block diagram of an exemplary computer system useful for 
implementing the invention; 

FIGS. 2 1 -24 are exemplary graphical user interfaces to enable a subscriber 
to engage in trading according to an embodiment of the invention 

FIG. 25 is a block diagram illustrating data flow and formatting between 
the exchange system and a subscriber; 

FIG. 26 is a block diagram illustrating the data transformation and 
mapping (DTM) process of the invention; 

FIGS. 27A and 27B are block diagrams illustrating the system architecture 
of a second embodiment of the invention, showing network connectivity among 
the various components; and 

FIG. 28 is a high level block diagram showing the interfaces that occur 
during the operation of the exchange system according to the second embodiment 
of the invention. 
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Detailed Description of the Preferred Embodiments 



Overview 



The invention relates to a system, method, and computer program product 
for analyzing, valuating, buying and selling financial products, such as loans. The 
loans contemplated for use with the invention include, for example, conforming 
and non-conforming loans, such as fixed, adjustable, and balloon mortgages, 
residential mortgage loans, multi-family mortgage loans, commercial mortgage 
loans, consumer and commercial installment loans, small business loans, student 
loans and vehicle/boat/plane loans. 

Although the embodiment described herein relates specifically to loans, it 
would be apparent to one skilled in the relevant art(s) that the invention could also 
be used for analyzing, valuating, buying and selling a variety of other financial 
products, including, for example: (1) revolving lines of credit, such as credit card 
accounts and home equity lines of credit, (2) annuities, (3) insurance products, (4) 
consumer and commercial assets, such as certificates of deposit, and (5) servicing 
rights. 

In an embodiment of the invention, an organization provides a centralized 
exchange system for loans. Subscribers to the system (i.e., brokers, 
correspondents, mortgage bankers, servicing companies, investors, capital markets 
brokers, etc.) may engage in trading that optimizes the types of loans being 
originated by lowering the risk associated with loan origination and maximizes 
return on each loan. 

The centralized exchange system of the invention creates a marketplace 
for trading in financial products, such as loan products. What is meant by 
marketplace, is a central service that each entity in the above-described loan life 
cycle can use for handling of loans. This type of system is referred to as an "end- 
to-end" system, because it is developed for each entity from the beginning to the 
end of the loan life cycle 100. The centralized system can also handle just a 
portion of the "end-to-end" system by integration with a subscriber's system. For 
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example, if a subscriber has its own loan origination system, the system of the 
invention can be integrated with this subscriber's system to allow for originated 
loans from the subscriber's system to be uploaded into the system of the invention 
for sale. 

Some of the features provided by the system of the invention include loan 
origination, loan pooling, publishing loans and loan pools for sale, and negotiating 
for sale of loans or loan pools. Further, the centralized exchange system provides 
connection to certain service providers for services such as automatic institution 
of due diligence investigations and/or loan servicing. The centralized exchange 
system also archives and/or warehouses trading data, servicing data and other loan 
data to provide risk-return information based on certain criteria (e.g., mortgage 
insurance data, future loan value index, pricing model, and historical valuation 
data). Still further, the centralized exchange system stores subscribers' trading 
rules and can notify a subscriber when loan products complying with its rules are 
published. The centralized exchange system may also notify subscribers (e.g., by 
electronic mail, pager, telephone, cellular telephone, personal digital assistant 
facsimile, etc.) when an offer for a loan or loan pool has been made and/or when 
an offer has been accepted or rejected. 

Such a system could allow industry participants such as brokers, 
correspondents, mortgage bankers, servicing companies, investors, and capital 
markets brokers to intelligently originate and trade in loans not only to better 
hedge against risks, but also to speculate for profit. 

In addition, information such as whether an applicant or census tract of 
property qualifies under the Community Reinvestment Act (CRA), will also be 
available. The information on loans which would qualify under the CRA would 
be helpful to buyers who are looking to fulfill federally mandated requirements for 
the purchasing of CRA-type loans. By flagging loans that meet CRA 
requirements, the invention offers buyers a centralized location to quickly find 
qualified loans and meet their federal purchase obligations. 

In one embodiment of the invention, additional value added services may 
also be available to the subscriber, such as automated underwriting, automated 
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pricing, rate locking, loan product comparison mapping, credit scoring, credit 
updates, CRA qualification and appraisal updates. 

The centralized exchange system provider organization supplies an 
infrastructure, secure protocol, and facilities so that subscribers may utilize the 
network to address their trading needs with little or no modification to the 
subscriber's current infrastructure required for use of the system of the invention. 
As detailed above with reference to FIG. 1, the invention addresses the trading 
needs of the subscribers summarized in Table 1 below. The subscriber names 
presented in Table 1 are given by way of example, and, as will be apparent to one 
skilled in the relevant art(s), may vary according to industry custom. 







Marketing Company 


Entities lhat advertise lenders' financial products to 
Consumers (phase 104). 


Broker 


individuals hired on an agent basis who bring together 
borrowers and lenders (phase 108). 


Mortgage Bank 
Correspondent 


Banks or other lending entities that market and 
originate loans directly to consumers. They typically 
then sell the individual loans or loan pools (phases 
104-108). 


Servicing Company 


Entities that, on behalf of owner of the loan, monitor 
and collect monthly payments from the Borrower, and 
may institute proceedings against borrower who are 
delinquent or in default (phases 120-124). 


Mortgage Banker 


Entities that purchase loans(in flow or in bulk) from 
different Lenders and then separately pool them 
together for resale (phase 1 12). 


Investor 


Entities that purchase loan pools from wholesalers and 
group the pools together to create mortgage-backed 
securities (i.e., securitization), which are then typically 
sold in the secondary market (phases 1 16). 


Capital Markets 
Broker/Brokerage Company 


Entities lhat act on an agent basis to bring together 
Investors and Buyers (phase 1 16). 


Securities Credit Rating 
Agency 


Entities that, typically on behalf of brokerage 
companies, rate (i.e.. determine overcapitalization) the 
mortgage-backed securities created by Investors 
(phase 116). 
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;!;-." : :- Subscriber t v : 




Securities Buyer 


Individuals or Entities that purchase (and trade) 
mortgage-backed securities (phase 116). 



Table 1 



Each subscriber of the centralized exchange system supplies the system 
with information about its trade activities with each of the other subscribers on the 
system. The centralized exchange system uses this information along with market 
data in several ways as will be described below. 

The invention is described in terms of the above example. This is for 
convenience only and is not intended to limit the application of the invention. In 
fact, after reading the following description, it will be apparent to one skilled in 
the relevant art(s) how to implement the following invention in alternative 
embodiments (e.g., other types of loans and other financial products). 

The terms "subscriber," "user," "person," "buyer," and "seller" are used 
interchangeably throughout herein to refer to those who would access and use the 
exchange system of the invention. 

//. Criteria for Evaluating a Loan 

The embodiment of the invention discussed herein relates to the trading 
of loans, and, thus, relates to the valuation of the loans and loan pools. In the 
relevant art(s), certain criteria are commonly used for the valuation of loans. In 
an embodiment of the invention, subscribers can create, remove and modify rules, 
based on these criteria, to set up a subscriber's own "preselected rules" to filter 
the loan or loan packages before purchase. Examples of these loan valuation 
criteria are provided in Table 2 below. 
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Loan Amount 
Credit Score 

Appraisal Value of Property 
Total Monthly Income 
Total Monthry Debt 
Assets and Liabilities 
Term of Loan 
Type of Loan 
Interest Rate 
Loan/Value Ratio 
Debt/Income Ratio 
Purchase Balance 
Original Balance 

State 

Table 2 



As will be apparent to one skilled in the relevant art(s), many other criteria may 
exist on which subscribers may wish to base their purchase rules. 

An example of a preselected rule that a buyer may use is if the buyer wants 
to purchase only those loans with an interest rate of 13% or greater and a 
loan/value ratio of 1 1 5 or less. Different buyer companies create their own rules, 
according to their business model. Companies use these rules to filter available 
loans to minimize risks associated with purchasing loans. These rules can be 
preselected and incorporated into a Rules Based Filter in the exchange system of 
the invention. Further, the subscribers can access historical loan data via the 
system of the invention to develop new rules to further assist in minimizing risk. 

In one embodiment, subscribers can monitor other subscriber's rules in 
order to originate or acquire loans or loan pools that will be easy to sell and that 
will command a higher price. Further, each subscriber can post program matrices, 
underwriting guidelines, and partner due diligence requirements, which assist 
sellers in determining potential buyers for their loan or loan pools and which assist 
buyers in analyzing the criteria used to originate loans that are for sale. 
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///. System Architecture 

Referring to FIG. 2, a block diagram illustrating the physical architecture 
of a centralized exchange system 200, according to a first embodiment of the 
invention, showing network connectivity among the various components, is 
shown. It should be understood that the particular centralized exchange system 
200 shown in FIG. 2 is for illustrative purposes only and does not limit the 
invention. 

The components of the exchange system 200, as shown in FIG. 2, are 
divided into two regions--"inside" and "outside." The components appearing in 
the inside region refer to those components that the exchange system provider 
organization would preferably have as part of their infrastructure in order to create 
a marketplace for online trading of financial products and provide the services 
contemplated by the invention. As will be apparent to one skilled in the relevant 
art(s), all of components "inside" of the centralized exchange system 200 are 
connected and communicate via a private wide or local area network (WAN or 
LAN 264). 

In contrast, the components appearing in the outside region refer to the 
infrastructure that the subscribers to the exchange system 200 would obtain or 
already have in place in order to participate in the exchange system 200. In this 
embodiment, the inside components and the outside components are connected 
via a secure exchange through the global Internet 260, running a secure 
communications protocol (e.g., secure sockets layer (SSL)), which includes the 
Worldwide Web (WWW) 266. In one embodiment, the connection to the Internet 
260 is through a router. In this embodiment, the router may be replicated 
("mirrored") for fault tolerance, as shown in FIG. 2 as routers 262a and 262b. 
As is well-known in the relevant art(s), routers, available from vendors such as 
Cisco Systems, Inc. of San Jose, CA, forward packets between networks. 

The exchange system 200 includes a trading subsystem 2 1 0. The trading 
subsystem 210 serves as the "back-bone" (i.e., trading processing system) of the 
invention. The trading subsystem 210 includes a trading server 202 and an 
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exchange system database server 207. The trading server 202 provides the "front- 
end" for the trading subsystem 210. Trading server 202 is a typical Web server 
process running at a Web site which sends out web pages in response to Hypertext 
Transfer Protocol (HTTP) requests from remote browsers (i.e., certain subscribers 
of the exchange system 200). That is, trading server 202 provides the graphical 
user interface (GUI) to certain users of the exchange system 200 in the form of 
Web pages. In an embodiment of the invention, trading server 202 may be 

implemented using a Windows NT™ server platform, and database server 207 

i 

may be a Sun SPARC station platform running the Solaris operating system. 

The exchange system database server 207 includes a trade database and 
a trading criteria archive. In an embodiment of the invention, these two databases 
are mirrored for fault tolerance and thus shown as databases 203a and 203b and 
archives 204a and 204b. The trading subsystem 2 1 0 also includes a securitization 
server 206 connected to a securitization database 205. 

The trading subsystem 2 1 0 also includes an administrative workstation 20 1 
(e.g., an IBM™ or compatible PC workstation running the Microsoft® Windows 
95/98™ or Windows NT™ operating system) that may be used to update, 
maintain, monitor, and log statistics related to the trading server 202 and the 
exchange system 200 in general (e.g., check cards, network connections, software, 
hardware, etc.). 

The exchange system 200 may also include a portfolio subsystem 220. 
The portfolio subsystem includes a portfolio server 224 that provides a GUI to 
certain users of the exchange system 200 in the form of Web pages. The portfolio 
server 224 is connected to one or more organization pool databases. In a first 
embodiment of the invention, there is an organization pool database that stores 
data for each organization that subscribes and posts pools to the exchange system 
200. For example, FIG. 2 shows an organization 1 pool database and an 
organization 2 pool database. Both of these databases are mirrored for fault 
tolerance and thus shown as pool databases 221a and 221b and 222a and 222b, 
respectively. The portfolio server 224 is also connected to a wholesaling criteria 
archive 223. 
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The wholesaling subsystem 220 also includes a boarding relay server 225 
which is connected to an origination archive 226. The relay server 225 allows 
data from the origination subsystem 240 (described below) to be collected and 
archived into the origination archive 226. This allows loan data to be immediately 
accessed by other subscribers of the system 200 {e.g., the servicing subsystem 
250). 

The exchange system 200 may also include a marketing subsystem 230. 
The marketing subsystem 230 includes a marketing database 23 1 connected to a 
marketing server 232 that provides a GUI to certain users of the exchange system 
200. 

The exchange system 200 may also include an origination server 270 and 
a bankruptcy server 290 that each provide a GUI to certain users of the exchange 
system 200. These two servers complete the inside region of the exchange system 
200. 

Within the outside region of exchange system 200 may be a loan 
origination subsystem 240. While one loan origination subsystem 240 is shown 
in FIG. 2, it will be apparent to one skilled in the relevant art(s) that a plurality of 
loan originating entities, each with their own loan origination subsystem 240 
infrastructure, may subscribe to the exchange system 200 and thus access the 
above-described components inside of the system. 

The loan origination subsystem 240 typically includes a loan origination 
interface 243 workstation. In an embodiment of the invention, a consumer (/.e., 
borrower) would call into the subsystem 240 via the public service telephone 
network (PSTN) 248 to apply for a loan. A customer service agent, working for 
the loan originating entity would gather the information using a GUI on the 
interface workstation 243 . Again, while one origination workstation 243 is shown 
in FIG. 2, it will be apparent to one skilled in the relevant art(s) that a loan 
origination entity will employ a plurality of customer service agents within a call 
center, thus necessitating a plurality of workstations 243. The workstation 243 
is connected to a loan origination server 242. Server 242 provides the back-end 
processing of the loan origination subsystem 240. The server 242 is connected to 
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an origination database 244 and a criteria database 245. The loan origination 
subsystem 240 also includes a manager workstation 246 which allows the manager 
of the loan origination entity to manipulate the data in the criteria database 245 
and perform supervisory functions over the customer service agents using the 
workstations 243 . The loan origination subsystem 240 also includes a router 247- 
-similar in functionality as routers 262a and 262b described above-which allows 
origination data to be securely uploaded to the inside of the exchange system 200 
via the Internet 260. 

During the loan origination process, the loan origination subsystem 240, 
via router 247 and the Internet 260, may obtain credit history data from a credit 
service bureau represented by a frame cloud 268. 

The outside region of exchange system 200 may also include a servicing 
subsystem 250. The servicing subsystem 250 typically includes a servicing server 
252 connected to a servicing database 251. Many servicing companies utilize 
mortgage service software such as the Mortgage Servicer Systems software 
available from Financial Industry Computer Systems (FICS) Group of Brussels, 
Belgium. Thus, the servicing database 25 1 could contain FICS data which would 
interface with the exchange system 200 via a router 253-similar in functionality 
as routers 262a, 262b and 247 described above- and the Internet 260. 

While one servicing subsystem 250 is shown in FIG. 2, it will be apparent 
to one skilled in the relevant art(s) that a plurality of loan servicing entities, each 
with their own loan servicing subsystem 240 infrastructure, may subscribe to the 
exchange system 200 and thus access the above-described components inside of 
the system. Loan servicing entities would provide exchange system 200 
subscribers, via the router 253 and the Internet 260, with information about each 
loan such as prepayment, delinquency, default, etc. In an embodiment of the 
invention, this information can be provided as continuous live data or via pre- 
scheduled (i.e., nightly, weekly, etc.) batch uploads. This allows exchange system 
200 subscribers to have up-to-date information about each loan within a pool for 
risk management analysis. 
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Also located in the outside region of the exchange system 200 are a 
plurality of workstations 280a-h which, via the WWW 266 (and thus, Internet 
260), access the components inside of the exchange system 200. As will be 
described in more detail below, FIG. 2 shows a workstation representative of 
each type of subscriber of the exchange system 200. As will be apparent to one 
skilled in the relevant art(s), each type of subscriber would be provided a different 
set of GUI screens to access their respective functions of interests within the 
exchange system 200. Accordingly, as suggested by FIG. 2, each type of 
subscriber would access a different subsystem inside of the exchange system 200 
(each with their own URL and servers providing the GUI screens). 

For example, rather than calling into the loan origination subsystem 240 
as described above, consumers may use the workstation 280b to apply for a loan. 
During processing of the loan, the system 200, via router 262a and/or 262b and 
the Internet 260, may obtain credit history data from a credit service bureau 
represented by the frame cloud 268. 

In an alternative embodiment of the invention, the workstations 280, and 
thus subscribers, may also access the exchange system 200 by a direct telephone 
dial-up connection without the need to go through the WWW 266 or the Internet 
260. 

In an embodiment of the invention, all of the servers (202, 206, 224, 225, 
232, 270, and 290) described above would be implemented using a Windows 
NT™ server platform. Furthermore, each workstation (201, 243, 246, and 280) 
described above can be realized with a PC workstation running the Microsoft® 
Windows operating system. The software and hardware architecture of exchange 
system 200 is described in more detail below with reference to FIG. 4. 

While a set of servers (/'.e., servers 202, 206, 224, 225, 232, 270, and 290) 
are shown in FIG. 2 for simplicity of explanation, it will be apparent to one skilled 
in the relevant art(s) that exchange system 200 may be run on a single server as 
well as in a distributed fashion over a plurality of the servers connected via LAN 
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201 . Further, in an alternate embodiment of the invention, exchange system 200 
may be structured as a multi-tier system rather than the client-server model 
presented herein. 

FIG. 2, also for simplicity of explanation, illustrates only one workstation 
280a-h for each type of subscriber to the exchange system 200. As will be 
apparent to one skilled in the relevant art(s), however, the workstations 280a-h 
represents the GUI interface provided to each type of subscriber and thus, a 
plurality of workstations 280a-h would exist in the system 200, each possibly 
residing at different physical locations and used by different subscribing entities. 

Similarly, while several databases (i.e., databases 203a, 203b, 204a, 204b, 
205, 221, 222, 223, 224, and 231) are shown in FIG. 2, it will be apparent to one 
skilled in the relevant art(s) that exchange system 200 may utilize databases 
physically located on one or more computers which may or may not be the same 
as their respective severs. ' Exchange system 200 may also utilize a different 
scheme for allocating where the data within the system physically resides. 

In a second embodiment of the invention, illustrated in FIGS. 27A and 
27B, the exchange system 2700 functions in much the same manner as exchange 
system 200. In FIG. 27A, the portfolio subsystem 220 is replaced by a 
correspondent delivery system 2720. Correspondent delivery system 2720 allows 
a subscriber to send loan(s) to another particular subscriber. In one embodiment, 
a subscriber may enter a contract with another subscriber to purchase a pre-set 
number of loans. Correspondent delivery system 2720 delivers these loans 
directly from the seller to the buyer. 

Correspondent delivery system 2720 includes a correspondent delivery 
server 2722 and a correspondent delivery system database server 2727. 
Correspondent delivery server 2722 provides the "front-end" for correspondent 
delivery system 2720. Server 2722 is a typical Web server process running at a 
Web site which sends out web pages in response to Hypertext Transfer Protocol 
(HTTP) requests from remote browsers (i.e., certain subscribers of the exchange 
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system 2700). That is, server 2722 provides the graphical user interface (GUI) 
to certain users of exchange system 2700 in the form of Web pages. In an 
embodiment of the invention, server 2722 may be implemented using a Windows 
NT™ server platform, and database server 2727 may be a Sun SPARC station 
platform running the Solaris operating system. 

Correspondent delivery system database server 2727 includes a 
correspondent delivery database and a correspondent delivery criteria archive. In 
an embodiment of the invention, these two databases are mirrored for fault 
tolerance and thus shown as databases 2723a and 2723b and archives 2724a and 
2724b. 

Correspondent delivery subsystem 2720 also includes an administrative 
workstation 2721 (e.g., an IBM™ or compatible PC workstation running the 
Microsoft® Windows 95/98™ or Windows NT™ operating system) that may 
be used by the correspondent organization subscriber to update, maintain, 
monitor, and log statistics related to server 2722 and exchange system 2700 in 
general (e.g., check cards, network connections, software, hardware, etc.). 

As shown in this embodiment in FIG. 27B, exchange system 2700 further 
includes a valued added subsystem 2730. Value added subsystem 2730 represents 
one or more subsystems that allow subscribers to perform various value added 
services, such as automated underwriting, automated pricing, rate locking, loan 
product comparison mapping, credit scoring, credit updates, CRA qualification 
and appraisal updates. 

For example, in the case of automated underwriting, the system 2700 and 
subsystem 2730 allow subscribers to run selected loans through an automated 
decision engine to perform automated underwriting on the selected loan(s). 
Similarly, in the automated pricing system, the system 2700 and subsystem 2730 
allow subscribers to run selected loans through an automated pricing engine to 
automatically assign a price to each selected loan. Each of the value added 
services listed above will be discussed in further detail below in Section X. 
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Value added subsystem 2730 includes a value added system server 2732 
and a value added system database server 2737. Value added system server 2732 
provides the "front-end" for each of the value added services available through 
subsystem 2730. Value added system server 2732 is a typical Web server process 
running at a Web site which sends out web pages in response to Hypertext 
Transfer Protocol (HTTP) requests from remote browsers (i.e., certain subscribers 
of the exchange system 2700). That is, server 2732 provides the graphical user 
interface (GUI) to certain users of exchange system 2700 in the form of Web 
pages. In an embodiment of the invention, server 2732 may be implemented using 
a Windows NT™ server platform, and database server 2737 may be a Sun 
SPARC station platform running the Solaris operating system. 

Value added system database server 2737 includes a rules database and a 
historical loan data archive. In an embodiment of the invention, these two 
databases are mirrored for fault tolerance and thus shown as databases 2733a and 
2733b and archives 2734a and 2734b. 

Value added subsystem 2730 also includes an administrative workstation 
2731 (e.g., an IBM™ or compatible PC workstation running the Microsoft® 
Windows 95/98™ or Windows NT™ operating system) that may be used by the 
subscriber to update, maintain, monitor, and log rules, filters and statistics related 
to server 2732 and exchange system 2700 in general (e.g., check cards, network 
connections, softwares-hardware, etc.). 

As will be apparent to one skilled in the relevant art(s), all of components 
"inside" of the system 2700 are connected and communicate with routers 262a 
and 262b via a private wide or local area network (WAN or LAN 264). Similarly, 
all of the components 11 inside" of the system 2700 are connected and communicate 
with each other via a private wide or local area network (WAN or LAN 2764). 

More detailed descriptions of the components of exchange systems 200 
and 2700, as well as their functionality, are provided below. However, a summary 
of the databases in each system is provided in Table 3 below. 
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Trade Data 203a, 203b 


Contains results data, pool negotiating (bidding) data, 
and financial data (e.g.. prime rate, Dow Jones 
Industrial Average, etc.) 


Trading Criteria Archive 204a, 
204b 


Contains rules used by subscribers to identify loans 
and loan packages to purchase. An example rule may 
be: 

f (FICO > 400) AND (AppraisaLValuejrf property > 
$30O ? 000) ] 


Securitization 205 


Contains mortgage-backed securities (e.g. bond) data 
and criteria 


Poo! Data Org N 221. 222 


Contains data of published pools for each of N 
mortgage bankers thai subscribes to exchange system 
200. 


Wholesale Criteria Archive 223 


Contains rules used by mortgage bankers to identify 
loans and loan pools to purchase. 


Origination Archive 224 


Contains origination data uploaded from origination 
entities subscribing to exchange system 200. 


Marketing 231 


Contains list of contacts (i.e.. people), and correlations 
to financial products likely to be or actually owned, 
and financial products they arc likely to purchase. 


Origination Data 244 


Contains information gathered from borrowers and 
stored locally at each loan origination subsystem 240 


Origination Criteria 245 


Contains rules used by loan originators to identify 
consumers whom to approve loans to. 


Servicing 251 


Contains data relevant to servicing of loans such as 
payment history, default, call (enforcement) history, 
eta 


Correspondent Trade Data 
2723a, 2723b 


Contains data relating to the loans transferred from a 
particular correspondent subscriber to a particular 
buyer and data relating to loans refused by buyer. 


Correspondent Criteria Archive 
2724a. 2724b 


Contains rules used by buyers to accept and approve 
loans from correspondent subscribers. 


Automated Decision Rules Data 
2733a, 2733b 


Contains rules used to perform automated 
underwriting of a loan. 


Automated Decision Loan Data 
Archive 2734a, 2734b 


Contains loan data on loans processed through the 
automated decisions subsystem. 



Table 3 
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IV. Secure System Interfaces 

Referring to FIG. 3, a high level block diagram shows the secure system 
interfaces 300 that occur during the operation of exchange system 200 according 
to an embodiment of the invention. As shown by the arrows connecting the 
various interfaces to system 200, subscribers (e.g., brokers, correspondents, 
mortgage bankers, servicing companies, investors, capital markets brokers, etc.) 
can access system 200 in order to upload and/or download information. As will 
be apparent to one skilled in the relevant art(s), such system access described 
below can occur via workstations 280a-280h, where the corresponding server 
(e.g., 202, 206, 224, 225, 232, 270, and 290) provides a GUI, and data is passed 
to and from databases 203a, 203b, 204a, 204b, 205, 221, 222, 223, 224, and 23 1, 
as applicable. 

A secure marketing interface 304 allows marketing companies to access 
system 200 via workstation 280a. Marketing companies retrieve information from 
system 200 such as which of their mailings resulted in loans being originated. 
Further, marketing companies can retrieve information from system 200 relating 
to which loan applicants, who were originally targeted by their mailings, were 
denied loans. Further, the marketing companies can access rules predefined by the 
loan originators {e.g., zip codes, age, geographic region, etc.), so that they can 
accurately target those potential borrowers that fit within the originators' 
requirements. Interface 304 also shows that the marketing companies send 
information back to system 200. Such information may include a list of those 
individuals who received a mailing regarding a specific loan product. 

A secure interface 308 allows data flow between system 200 and a loan 
origination company (/.e., a bank or other commercial lender) via loan origination 
subsystem 240. A loan originator will collect loan origination information from 
an applicant (i.e., consumer), usually via the telephone or via the applicant 
entering some origination information via workstation 280b. This information is 
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then forwarded by system 200 to loan origination subsystem 240 via the WWW 
266. 

The loan originator will then use the information collected to process the 
loan and forward information regarding whether the application was approved or 
denied to the system 200. This information is then archived in origination archive 
226 so that it may be accessed in some form by other subscribers of the system 
200. 

The loan originator, once it has originated a loan or a pool of loans, may 
send information concerning the loan(s) to the system 200 to post or publish the 
loans for sale to mortgage bankers. 

A secure interface 3 12 allows mortgage bankers to access system 200, via 
workstation 280f to (1) pool its own loans together for resale, and/or (2) search 
for loans that have been posted for sale by loan originators or other mortgage 
bankers for sale. 

In the first instance, an investor may use workstation 280f to review its 
loans and to search through the loan data using various criteria to select particular 
loans to be pooled together for sale. These loan pools are stored in databases 22 1 
and 222. Once a mortgage banker has created a loan pool, he can publish it by 
sending it to the exchange system 210 to be published. 

In the second instance, investors use workstation 280d to access system 
200 to look for loans for sale. The investors then input an offer for certain loans 
that meet their predefined rules. 

As discussed in further detail below, the mortgage bankers' predefined 
rules, that were created, deleted and/or modified by the subscriber, are archived 
in criteria archive 223 and are accessible to the loan originators. As such, the loan 
originators can review these predefined rules before originating a loan to make 
sure that its loans will be attractive to the mortgage bankers. This process 
maximizes returns. 
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In one embodiment of the invention, the mortgage bankers can register 
with system 200 to be notified if any loans are posted for sale that fall within its 
predefined rules. Such notification can be made via electronic mail, any type of 
digital/wireless communications (e.g., by pager, telephone, cellular telephone, 
facsimile, personal digital assistant, etc, possibly using Hand-held Device Markup 
Language (HDML), Voice Markup Language (VoxML), extensible Markup 
Language (XML), or other similar computer language) or simply upon accessing 
system 200 via a GUI dialogue box. Further, a seller can contact a particular 
buyer via system 200 if it has a loan for sale that it believes the buyer would be 
likely to purchase. 

The mortgage bankers can search the available loans on system 200 using 
various search criteria, either based on the mortgage bankers' predefined rules, or 
based on some other criteria, to quickly locate those loans that meet their 
requirements. For example, if a mortgage banker wants to purchase only loans 
made to borrowers having a FICO score greater than 600 and an interest rate of 
13% or greater, the mortgage banker could use system 200 to search for loans 
having these criteria. Similarly, the mortgage banker couid have predefined rules, 
using these criteria, so that they can be notified when such loans, meeting these 
criteria, are posted for sale. 

Once the investor makes an offer for a loan that is accepted by the seller, 
the mortgage banker must perform a due diligence analysis on the loan to be 
purchased to make sure it is a valid loan. In an embodiment of the invention, 
mortgage bankers can authorize system 200 to automatically initiate transfer of 
loan files from the seller to a trust company and/or loan custodian upon purchase 
of a loan by the mortgage banker. The mortgage banker can select one or more 
particular trust companies and/or loan custodians in advance for all of its loans. 

In one embodiment, the mortgage banker simply enters an address to 
which a hard copy of the loan file is to be sent. In another embodiment, the 
documents in the loan file are scanned and uploaded to the exchange system of the 
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invention. Once the exchange system receives authorization from the seller, the 
data file containing the scanned documents from the loan file is transferred to the 
mortgage banker (e.g, the buyer), transferred directly to the buyer's trust company 
to perform the due diligence analysis of the loan, or transferred directly to the 
buyer's loan custodian for safekeeping. 

A secure interface 316 allows trust companies to access system 200 via 
workstation 280c. Upon receipt of the loan files, the trust company will perform 
a due diligence analysis on the loan (or on a statistical sampling of several loans 
from a pool of loans). The due diligence analysis will ensure that the supporting 
documentation provided by the borrower matches the information the lender relied 
on in approving the loan (i.e., the information entered into the loan application). 
Once the due diligence is completed, the trust company will forward a certificate 
to the mortgage banker which includes verification of the authenticity of the 
loan(s). 

Once the mortgage banker has accumulated several loans, the workstation 
280f, as discussed above, can be used to post or publish a pool of these acquired 
loans for sale. 

A secure interface 320 allows securitization companies to access system 
200 to (1) search for loan pools that have been posted on system 200 for sale by 
mortgage bankers and (2) to sell mortgage-backed securities that they have 
created and backed with their loan pools. 

In the first instance, the securitization companies access system 200 via 
workstation 280d to look for loan pools for sale and to review information for 
each loan in a pool and individually accept, deny, or suspend its decision for each 
loan within the pool. This will result in a revised loan pool for which the 
securitization company may make an offer. The mortgage banker can then access, 
via interface 312, the revised loan pool, and either accept the securitization 
company's offer, create another pool to offer for sale, or reject the offer. 
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As discussed above, the seller, in this case the investor, can access the 
securitization companies' predefined rules, which are stored in the securitization 
database 205, before posting a loan pool so that a pool that will look particularly 
attractive to a buyer/investor can be created, thereby maximizing their chances of 
selling the pool. In one embodiment of the invention, the securitization companies 
can ask to be notified by system 200 if any loan pools are posted that fall within 
its predefined rules. Such notification can be made via electronic mail, any type 
of digital/wireless communications (e.g., pager, telephone, cellular telephone, 
facsimile, personal digital assistant, etc., possibly using HDML, VoxML, XML, 
or other similar computer language) or simply upon accessing the system 200 via 
a GUI dialogue box. Further, a seller can contact a particular securitization 
company via system 200 if it has a loan pool for sale that it thinks the 
securitization company would be likely to purchase. 

The securitization companies can search the available loan pools on system 
200 using various search criteria, either based on the predefined rules, or based 
on some other criteria, to quickly locate those loan pools having loans that meet 
its requirements. Further, the securitization companies can search within a 
selected loan pool to automatically decline or accept particular loans within a pool 
that have certain criteria. For example, if a securitization company desires to 
purchase only loan pools having loans made to borrowers having a FICO score 
greater than 650 and an interest rate of 12% or greater, the securitization 
company could use system 200 to search for loans having these criteria. Similarly, 
the securitization companies could have predefined rules, using these criteria, so 
that it can be notified when such loan pools, meeting these rules, are posted for 
sale. 

Once the investor has acquired several loan pools, it can access system 200 
via workstation 280e to group together the loan pools to back a security (i.e., 
create a mortgage-backed security). As shown in FIG. 3, an interface 324 allows 
the brokerage companies to be able to access system 200 via a workstation 280d 
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to look for mortgage-backed securities for sale and to negotiate to buy and sell the 
mortgage-backed securities. 

Because the loans are being used as collateral to back a security, they 
cannot be resold. As such, the securitization company is responsible for servicing 
the loans for the remainder of their lifetime. This task is often delegated to a 
servicing company, as discussed below. 

A secure interface 328 allows a servicing company, via workstation 280h, 
to access the exchange system 200 to acquire loan information on the loans it has 
been asked to service and to provide information back to system 200, such as 
payment history, prepayment rates and/or default. 

A secure interface 332 allows trading organization personnel, via the 
administrative workstation 201, as well as all subscribers via workstation 280g, 
to access exchange system 200 in order to perform certain risk management 
functions. For example, a mortgage banker who is thinking about purchasing a 
particular loan, may access data in database 203a to determine what a fair price 
for a particular loan or loan pool might be, based on previous trades of similar 
loans. 

A secure interface 336 allows a credit rating agency, typically hired by the 
brokerage firm to rate a mortgage-backed security, to access exchange system 200 
to review the payment history and risk-return information in order to rate a 
particular security. For example, the credit rating agency can review the payment 
history of the loans used to back a particular mortgage-backed security, to 
determine whether the loans are likely to be prepaid or go into default. 

A secure interface 340 allows subscribers to access various value added 
services available via exchange system 200, such as automated underwriting, 
automated pricing and other value added services, as discussed below in 
Section X. 

Referring now to FIG. 28, a second embodiment of the present invention 
shows the secure system interfaces 2800 that occur during operation of exchange 
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system 2700. A centralized trading system 2802 is provided. In this embodiment, 
system 2802 is divided into an open trading platform 2804 and a correspondent 
delivery system (CDS) platform 2806. Open trading platform 2804 is that part of 
system 2802 that is open for access by all subscribers for trading loans via 
exchange system 2700, as described above with respect to FIG. 3. 

CDS platform 2806 is a portion of system 2802 that is dedicated to a 
particular business-to-business transfer of loans. Particular correspondents who 
have contractual obligations to a particular buyer to provide the buyer with loans 
can use CDS platform 2806 to pass these loans to the buyer The correspondent 
can forward these loans one-by-one, i.e., flow, or several at a time, i.e., bulk. The 
arrows shown in FIG. 28 differentiate between flowed loans, shown with the 
dashed-Iine arrows, and bulk loans, shown with the solid line arrow. 

As shown by the arrows connecting the various interfaces to system 2802, 
subscribers can access system 2802 in order to upload and/or download 
information. As will be apparent to one skilled in the relevant art(s), such system 
access described below can occur via workstations 280a-280h, where the 
corresponding server (e.g., 202, 2722 and 2732) provides a GUI, and data is 
passed to and from databases 203a, 203b, 204a, 204b, 205, 2723a, 2723b, 2724a, 
2724b, 2733a, 2733b, 2734a and 2734b, as applicable. 

A secure interface 2808 allows open correspondent subscribers to access 
open trading platform 2804 of system 2802 via a workstation, as described above 
with reference to FIG. 3. 

Secure interfaces 2810 and 2812 allow data flow between flow or bulk 
correspondent subscribers and CDS platform 2808 of system 2802. In the 
embodiment shown in FIG. 28, secure interfaces 2810 and 2812 link subscribers 
to system 2802 via an interface 2814. For example, a particular buyer can use 
CDS platform 2806 to receive loans from its correspondents. The buyer can 
provide a link on its own interface 2814 (e.g., a Web site) to system 2802. As 
such, in one embodiment, the flow and loan correspondent subscribers would 
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access their dedicated buyer* s Web site and upload the loan information via secure 
interfaces 2810 and 2812. The loan information is passed through interface 2814 
to CDS platform 2806. In one embodiment, the transfer of data is transparent to 
the flow and bulk correspondent subscribers. As would be apparent to one skilled 
in the art, in another embodiment the flow and/or bulk correspondent subscribers 
could access CDS platform 2806 directly, rather than accessing it through 
interface 2814. 

In the case of bulk interface 28 1 2, this interface includes a GUI that allows 
the subscriber to select which loans to include in the bulk transfer, similar to the 
interface discussed above with respect to workstation 280f which can be used by 
a seller to create a pool of loans for sale on the exchange system. 

Once the CDS platform 2806 receives the loan data, it performs data 
transformation and mapping, as discussed below with reference to FIGS. 25 and 
26, to convert the data to match the data formats used by the buyer. CDS 
platform 2806 will then make an automated determination whether submitted 
loans meet purchase criteria as defined by the buyer company by performing 
automated underwriting of the loan. This eliminates the need for manual review 
of the loan information. Loans meeting the criteria and data validation checks will 
be identified and available for sending to a proprietary backoffice 28 1 6. Loans not 
meeting the criteria and/or data validation checks will be flagged for the buyer 
company to either override or send back to the correspondent subscriber with a 
reason for the rejection. The CDS platform 2806 may also perform other 
automated functions, such as automated pricing, slotting or loan classification, and 
rate locking of loans passed through the platform. 

The data is then passed, in bulk or flow, to backoffice 2816 of the 
particular buyer. As shown by way of example only, a backoffice 2816 may 
include a loan origination interface 2818, an automated underwriting interface 
2820 and/or a bulk bids interface 2822. Loan origination interface 28 1 8 actually 
boards the loans sent by the correspondent onto the buyer's backoffice system. 
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Automated underwriting interface 2820 is used to pass the loan data through the 
buyer's own underwriting program. Bulk bids interface 2822 is used to allow a 
buyer to accept or decline individual loans in a bulk sale and to make pricing 
decisions on a bulk loan sale. As would be apparent to one skilled in the relevant 
art, the system of the invention could be configured to transfer the loan data to 
various other interfaces/systems, suited for a particular buyer's backoffice system. 
Further, it would be apparent to one skilled in the relevant art that the system of 
the invention could be configured to allows subscribers to choose from among 
multiple backoffices 2816 so that a subscriber could shop the loan to several 
different prospective buyers via CDS platform 2806. 

In an embodiment of the invention, the subscriber also has access via CDS 
platform 2806 and/or open trading platform 2804 to various subscriber tools and 
value added services, discussed in detail below in Sections IX and X. 

BackOffice 2816 will send information back to the subscribers via CDS 
platform 2806. This information may include, for example, whether the buyer will 
fund a particular loan application, whether the buyer will accept a closed loan 
(e.g., already funded), and/or whether additional loan information is required by 
the buyer before the loan(s) will be approved. If a loan is approved, the trade may 
continue, as discussed above with regard to due diligence, etc. If the buyer 
refuses to accept a particular loan, the correspondent subscriber could then use 
open trading platform 2804 to try to sell the loan on system 2802 to another 
buyer. 

V. Software/Hardware Architecture 

Referring to FIG. 4, a simplified block diagram illustrating a 
software/hardware architecture 400 according to an embodiment of exchange 
system 200, showing communications among the various components, is shown. 
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The architecture 400 of exchange system 200 includes software code that 
implements the interfaces 300 (via the workstations 280) during the operation of 
exchange system 200. 

Architecture 400 includes a database 402 which represents any one of the 
collection of database within the inside region of exchange system 200 (i.e., 
databases 203a, 203b, 204a, 204b, 205, 221, 222, 223, and 224). In an 
embodiment of the invention, database 402 may be implemented using a high-end 
object-oriented database product such as ObjectStore™ available from Object 
Design, Inc. of Burlington, MA, or a relational database such as Oracle. As is 
well known in the relevant art(s), in an object-oriented database, data is stored as 
objects and can be interpreted only using the methods specified by its class. The 
relationship between similar objects is preserved as are references between 
objects. This allows queries to be faster than with relational databases because an 
object can be retrieved directly without a search, by following its object identifier. 

The database 402 is connected to a Web server 404 which represents any 
one of the collection of servers within the inside region of exchange system 200 
(i.e., servers 202, 206, 224, 225, 270, and 290). As mentioned above, in an 
embodiment of the invention, all of the servers would be implemented using a 
Windows NT™ server platform running ("back-end") software implemented in 
a high level programming language such as the C++ programming language. 

In an embodiment of the invention, the server 404 software application 
communicates with the database 402 using a C++ object interface. In the special 
case of the trading subsystem server 202, the database sever 207 (not represented 
in FIG. 4) interconnects it to the databases 203a and 204a. In an embodiment of 
the invention, the server 207 is a Sun SPARC workstation running the Solaris 
operating system that provides highly scaleable hardware solutions. The trading 
subsystem server 202 then performs the management (i.e., opening, closing, etc.) 
of sessions. 
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The database server 207 would communicate with the databases 203a and 
204a, and the server 202 using a structured query language (SQL) commands 
interface. 

The sever 404 also provides the secure GUI "front-end" for exchange 
system 200. The GUI front-end can be customized for each type of subscriber to 
the system. In an embodiment of the invention, the front-end is implemented 
using the Active Server Pages (ASP), Visual BASIC (VB) script, and 
JavaScript™ sever-side scripting environments that allow the creation of dynamic 
Web pages. The subscriber may use custom software to allow the user to deliver 
a binary or ASCII file as part of an HTTP form submission. 

These Web pages are provided to the subscribers of the exchange system 
200 via the workstations 280a-h (collectively shown as "Web Clients" 406), using 
the Hypertext Transfer Protocol (HTTP) thereby providing the front-end to the 
subscribers 408 (e.g., borrowers, brokers, correspondents, mortgage bankers, 
servicing companies, investors, capital markets brokers, etc.). The user interface 
for Web Clients 406 is browser implemented, using Java, JavaScript™, and 
Hypertext Markup Language (HTML). As such, the external workstations 222 
and the internal workstations 224 may be realized with IBM™ (or compatible) 
PCS running the Windows NT™ or Windows 95/98™ operating system. 

In an embodiment of the invention, as mentioned above, subscribers 408 
may request that system 200 notify them if any loans, loan pools, or desired 
information which fall within its predefined rules are available. As discussed 
above, such notification can be made via electronic mail, any type of 
digital/wireless communications or simply upon accessing the system 200 via a 
GUI dialogue box. Thus, the server 404 also communicates with the Web clients 
406 via the well-known Secure Multipurpose Internet Mail Extensions (S/MIME) 
or Simple Mail Transfer Protocol (SMTP) protocols for electronic mail. Also, the 
server 404, as suggested by FIG. 4, may also communicate directly with the 
subscribers 408 by any known digital/wireless communication means (e.g., by 
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pager, telephone, facsimile, cellular telephone, personal digital assistant, etc., 
possibly running HDML, VoxML, XML, or other similar computer language). 

VI. System Operation 

A Marketing 

Referring to FIG. 5, a flow chart 500 representing an exemplary 
interaction between a marketing company and system 200 in an embodiment of 
the invention is shown. 

In a first step 504, the marketing company selects potential loan candidates 
for a marketing campaign and targets those candidates via direct mailings, TV, 
print adds, or other similar marketing techniques. In the invention, the potential 
loan candidates may be targeted based on whether their credit or personal 
information matches rules predefined by lenders. 

In a step 508, the marketing company then sends the relevant data to 
system 200. This data may include, in the case of direct marketing, a list of the 
names of each individual who received a mailing. In the case of TV or print ad 
campaigns, the data may include a set of criteria which was used to target the 
market for the campaign. For example, the marketing company may have decided 
to target individuals between the ages of thirty and forty, and with an annual gross 
income of greater than $75,000. In this case, the TV and print ads would appear 
on programs or in newspapers and magazines typically seen by people that fit 
these criteria. 

In step 510, the relevant data from the marketing company is translated 
into an appropriate processing format for system 200 using a Data Transformation 
and Mapping (DTM) process. The DTM process is further discussed below with 
reference to FIGS. 25 and 26. 
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In a step 5 1 2, system 200 collects information from loan applicants. This 
data may come from different sources. For example, the loan applicant may enter 
the data directly into system 200 by applying for a loan via workstation 280b. 
Alternatively, a loan agent at the loan origination subsystem 240 may enter the 
data into system 200 based on the information collected from the applicant via 
loan origination interface 243 taken over the phone. In the latter case, the 
collected loan origination information is uploaded from subsystem 240 to system 
200 at pre-determined intervals. In one embodiment, this upload occurs once 
daily. This loan applicant information may include, for example, the loan 
applicant ' s name, address, age, annual or monthly gross income, how the applicant 
heard about the particular loan product, and whether the loan applicant ' s loan was 
approved. 

In a step 516, system 200 correlates or matches the loan applicant 
information with the candidate information from the marketing company to 
generate response data, which indicates those applicants who responded as a 
result of the marketing company's campaign. This response data is sent back to 
marketing subsystem 230 via router 262a and archived in database 23 1. 

In a step 518, system 200 uses the DTM process to send the correlated 
response data to the Marketing company in a preselected format. The DTM 
process is discussed below with reference to FIGS. 25 and 26. 

In a step 520, the marketing company retrieves the response data from 
database 23 1 of subsystem 230, and uses this response data in step 504 to develop 
the next set of criteria to use to target potential candidates. The response data 
may be uploaded from loan origination subsystem 240 via router 262a and into 
database 23 1 at regular intervals. In one embodiment of the invention, upload of 
this response data occurs once daily. 

This type of marketing information is also valuable for reselling and/or 
cross selling to particular borrower. As such, the system of the invention also 
archives the marketing data and borrower information. 
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R Loan Origination 

Referring to FIG. 6, a flow chart 600 representing an exemplary 
interaction between a loan originator and system 200 in an embodiment of the 
invention is shown. 

In a step 604 of flow chart 600, a loan agent at the loan originator obtains 
loan application data from a potential borrower. This data can be obtained by the 
loan agent via system 200. For example, if the potential borrower applies for the 
loan on-line, at the system web site, system 200 will then notify the loan originator 
of the loan application and may download the loan application data to loan 
origination subsystem 240 for processing. Alternatively, the loan application data 
may be obtained by the loan agent via a call center, in which the applicant calls 
into the call center and provides his information to the loan agent over the 
telephone. In this case, the loan agent may enter the loan application data via loan 
origination interface 243 for subsequent uploading to system 200. 

Before the loan information is received by system 200, the information is 
translated into the correct processing format using the DTM process which is 
discussed below in FIGS, 25 and 26. 

FIGS. 7-14 show exemplary Graphical User Interfaces (GUIs) of an 
embodiment of a loan origination system for use by a loan agent when interfacing 
with system 200. In a preferred embodiment of the invention, these GUIs are 
used on the loan agents' workstation, shown as loan origination interface 243. 

As shown in FIG. 7, a loan agent, Tom Smith, has a personal account on 
system 200, in which his current loan application data is stored. A GUI 702, 
shown in FIG. 7, includes a window 704 to display the primary applicant's name, 
the loan request amount and the status of the loan application. GUI 702 also 
provides the loan agent with a loan summary window 706 to display detailed 
information for each pending loan application. Each time a new loan application 
is initiated, the application is added to the loan agent's account. 
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As shown in FIG. 8 S to originate or update a loan application, system 200 
provides the loan agent with a GUI 802 that is divided into six separate screens, 
noted by the tabs 804, 806, 808, 810, 812 and 814 across the top of GUI 802. 
These tabs are labeled Personal, Employment, Property, Credit Report, Loan and 
Stipulations, respectively. 

A GUI 816 corresponding to tab 804 is shown in FIG. 8. GUI 816 
permits the loan agent to input each loan applicant's personal information directly 
into loan origination interface 243 . Examples of such personal information include 
the applicant's name, social security number, phone numbers, date of birth, 
addresses (current and previous) and nearest relative. 

A GUI 904 corresponding to tab 806 labeled "Employment" is shown in 
FIG. 9. GUI 904 permits the loan agent to input each loan applicant's 
employment information directly into loan origination interface 243 . Examples of 
such employment information include the name of the applicant's primary and 
secondary or previous employers, the applicant's job title, time at the job, 
supervisor, phone numbers, and income. An arrow 908 at the lower right corner 
of GUI 904 allows the loan agent to easily flip between the GUIs for each tab. 
Further, a loan status bar 912 at the top of GUI 904 depicts a graphical 
representation of the status of the loan application. Each of the GUIs shown in 
FIGS. 7-14 have a similar loan status bar 912. 

A GUI 1004 corresponding to tab 808 labeled Property is shown in FIG. 
10. GUI 1004 permits the loan agent to input information about the loan 
applicants' property directly into loan origination interface 243 . Examples of such 
information include the property address, property type, taxes, insurance costs, 
HO A dues and estimated value of the property. Additional tabs 1008 and 1012 
at the lower left of GUI 1 004 can be used to access additional GUIs (not shown) 
to input information regarding any liens on the property and the appraisal 
information for the property. 
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Referring to FIG. 1 1 , a GUI 1 1 04 corresponding to tab 8 1 0 labeled Credit 
Report is shown. GUI 1104 permits the loan agent to access summary 
information about each loan applicant's credit score from system 200. In one 
embodiment of the invention, the information relating to credit score is 
downloaded directly from a credit reporting agency via credit bureau frame cloud 
268. Additional tabs 1 108, 1 1 12, 1 1 16, 1 120 and 1 124 appear at the lower left 
of GUI 1 104. Tab 1 108 can be used to access an additional GUI (not shown) 
which includes more detailed information on the applicant's credit score. Tab 
1112 can be used to access an additional GUI (not shown) which includes 
information relating to the credit information for a joint applicant. Tab 1 1 16 can 
be used to access an additional GUI (not shown) which includes information 
relating to the loan application. Tab 1 1 20 can be used to access an additional GUI 
(not shown) which includes information relating to the applicant's spouse's credit 
report. Tab 1 1 24 can be used to access an additional GUI (not shown) which 
includes information relating to any inquiries that need to be made to confirm 
certain loan application information. 

Referring to FIG. 12, a GUI 1204 corresponding to tab 812 labeled 
"Loan" is shown. GUI 1204 permits the loan agent to input and access 
information about the loan directly into and from loan origination server 242. 
Examples of loan information which may be input by the loan agent, include 
amount requested, term, rate, loan type, points, loan to value ratio. Examples of 
loan information which are supplied by loan origination server 242 include, F1CO 
Score, income/debt ratio, disposable income, and savings and payment 
information. An additional tab 1208 appears at the lower left of GUI 1204. Tab 
1208 can be used to calculate loan fees associated with the applicant's loan. 

Referring to FIG. 13, a GUI 1304 corresponding to tab 814 labeled 
Stipulations is shown. GUI 1 304 permits the loan agent to set certain stipulations 
relating to the loan directly into system 200. Common stipulations appear in a 
window 1308 on the left side of GUI 1304. Examples of such common 
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stipulations include a requirement that for approval, the loan agent must obtain tax 
returns and W2 forms of the applicant for the past two years. Buttons 1 3 1 2 and 
1316 in the middle of GUI 1304 allow the loan agent to add and remove 
stipulations from the list in window 1308. An additional tab 1320 appears at the 
lower left of GUI 1304. Tab 1320 can be used to track the stipulations to mark 
when all of the stipulations have been met. 

Referring to FIG. 14, a GUI 1404 shows an interface that can be used by 
the loan agent to search the marketing database for preliminary applicant 
information. When a loan agent receives a call from an applicant, the marketing 
database can be searched, using, for example, the applicant's last name and zip 
code, as shown in windows 1408 and 1412, or using a priority code, as shown in 
a window 1416, to match the applicant with the pre-existing information in the 
marketing database. The search results are displayed in a window 1420. As 
shown in FIG. 14, depending on the detail of the search information, more than 
one match may appear in window 1420. The particular applicant's name is then 
highlighted, and the applicant information for that applicant is displayed to the 
right of window 1420. When the user depresses a button 1424, labeled "Qualify", 
the selected applicant's information is automatically entered into GUI 704 so that 
the loan agent must only verify this information and does not need to manually re- 
enter this information, thereby saving time. 

Returning now to FIG. 6, in a step 608, the loan originator requests a 
credit report from a credit reporting agency. In the embodiment shown in FIG. 
2, this request is sent to the credit reporting agency via credit bureau frame cloud 
268. System 200 is configured so that the information obtained from the credit 
agency is automatically entered into the proper cells in graphical user interfaces 
of the system. 

In a step 612, the loan originator may consult with portfolio subsystem 
220 or trading subsystem 210 for market data relating to the types of loans 
currently in demand and the predefined rules for wholesalers relating to loan 
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purchase. The information obtained by the loan originator is processed in 
exchange system 200 standardized XML format used by the DTM process as 
referenced below in FIGS. 25 and 26. This will enable the loan originator to know 
which types of loans to originate, and which types of borrowers look most 
attractive to the mortgage bankers. 

In a step 616, the loan agent then evaluates the applicant's loan 
information, including credit score, and determines whether to pre-approve the 
applicant's loan request. 

If the loan is not approved, loan application information is archived in a 
loan application data warehouse of system 200, as shown in a step 620. In the 
embodiment of the invention shown in FIG. 2, the loan application data 
warehouse includes, for example, databases 204a, 204b, 226 and 23 1 . As would 
be apparent to one skilled in the relevant art(s), the loan application data 
warehouse is a collection of databases, and provides programming logic to allow 
a user to access all of the data in the databases at the same time. Returning now 
to FIG. 6, the applicant is then notified that the loan was declined, as shown in a 
step 624 and the interface between the loan originator and system 200 ends at a 
step 648. 

If the loan is pre-approved, the loan application data is sent to the loan 
processor for processing and then to the underwriter for final approval, as shown 
in a step 632. There are similar GUIs (not shown) available through workstation 
243 of loan origination subsystem 240 for use by the loan processors and 
underwriters to process and approve the loan. 

In a step 636, the manager of the loan origination company then 
determines, using workstation 246, whether to give final approval to the 
applicant's loan request. If final approval is denied, the loan application data is 
archived in origination archive 226 of the loan application data warehouse, in step 
620 and the flow follows as described above. If the loan is given final approval, 
the loan originator and application proceed through loan closing in a step 636 and 
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funding is provided to the loan applicant in a step 640. Similar GUIs (not shown) 
are available through system 200 for use in loan closing step 636. 

In a step 644, the loan application data for the approved loans is sent to 
system 200 to be archived in origination archive 226 of the loan application data 
warehouse, and the interface between the loan originator and system 200 ends at 
step 648. As explained above, in one embodiment, the loan application data, 
including both data for approved and unapproved loans, is uploaded to origination 
archive 226 once daily. 

C Exchange System 200 

A person wishing to sell a loan or loan pool may access exchange system 
200 via workstation 280d to publish a loan or loan pool for sale. In the case of 
a loan pool, the seller may first access system 200 via workstation 280f to create 
the loan pool. Workstation 280f can be used to search currently available loans 
for a seller using certain predetermined criteria (e.g., FICO score, loan amount, 
loan term, CRA compliance, etc.) to generate a pool of loans satisfying the search 
criteria. This pool can then be saved and stored in databases 22 1 and 222 of 
portfolio subsystem 220. 

FIG. 15A is an example of bulk trading; however, the same system could 
be used for trading of a single loan. As shown in FIG. 1 5 A, a seller wishing to 
sell a loan or loan pool sends the loan information to the exchange system in step 



In step 1 504, before being forwarded to the exchange system, the loan 
information to be published by the seller undergoes a translation using a DTM 
process or other translation process. Translation products that may be used to 
implement this translation process include: Data Junction™ by Data Junction 
Corporation, DTS™ by Microsoft SQL Server. The DTM process of the present 
invention is described below with reference to FIG. 25. 
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In step 1506, the loan information is published for sale on exchange 
system 200. The seller can publish the loans either by entering the loan 
information manually or uploading via workstation 280d or retrieving the loan 
information from origination archive 226 or databases 221 and 222 of portfolio 
subsystem 220. 

In one embodiment, subscribers each have a profile archived in system 
200. The profile includes the subscriber's contact information, such as, the name 
of the company for which the subscriber works, the subscriber's telephone 
number(s), fax number(s), address information and electronic mail address 
information. The profile also includes a list of all loans or loan pools that have 
been published by the subscriber for sale in system 200. Other subscribers can 
access this profile information for review. The subscriber can also access his own 
profile to update the information therein. 

In one embodiment, the subscriber can set up his rules for his profile using 
the loan criteria to indicate the conditions under which the subscriber wishes to 
be notified by the system of a published loan or loan pool. The subscriber may 
mark these predefined rules to be public, available to all subscribers for review, 
or private, not accessible to other subscribers. Further, the subscriber may opt to 
have sensitive loan data, such as social security numbers and name, removed until 
the loan undergoes the due diligence process. In addition, the subscriber may opt 
to add expiration dates to offers, associate a particular "settle by" date, or have 
fees calculated automatically with bids. 

After the loan(s) are published, exchange system 200 will test the loan 
information against the preselected rules for its registered buyers applying a Rule 
Based Filter (RBF), as shown in a step 1508. The RBF is made up of standard 
and special components. The standard component comprises basic logic checks 
and rules established by the database operator. For example, the system may check 
to ensure that the loan amount is within a certain value range, or check the 
number of digits within the social security number. The special component is 
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comprised of user-defined rules which are typically applied in flow trading. For 
example, the user can specify that all LTV ratios above 100 should be blocked. 

If the loan survives a particular buyer's filter, exchange system 200 may 
notify the buyer or buyers of the publication of the loan(s), as shown in a step 
1512. This notification can occur in. a variety of ways, depending on the buyer's 
notification preference. For example, the exchange system 200 might send an 
automatic electronic mail, telephone call, facsimile, or page to the buyer with 
notification that a loan has been added that meets the buyer's criteria and advising 
the buyer to check the Web site via workstation 280d. Such notifications can be 
sent via electronic mail, pager, telephone, facsimile, cellular phone, or hand-held 
computer. 

In addition, the buyer can set up the account to monitor and "push" trading 
activity information to the user's computer screen-saver or window without 
having to be logged into the exchange system 200. This process of "pushing" uses 
the concept of instant messaging to listen for messages from the server and send 
notification of message to the subscriber's screen. In one embodiment, when the 
subscriber logs onto system 200, he receives a "buy alert" that displays new loans 
or loan pools that have entered the system 200 and that meet the subscriber's 
predefined rules. Also, while the subscriber is logged into his account on system 
200, a "buy alert" may flash on the subscriber's computer screen if a new loan or 
loan pool meeting his predefined rules enters the system. 

In one embodiment, a trading company profile may also be provided. If 
a subscriber is interested in a particular loan pool, he can use the trading company 
profile to find out information on the company that published the loan pool. This 
profile can include information such as contact information and contact persons 
at the trading company, years in business, net worth, financial product offerings, 
monthly loan volume and so on. 

If the loan does not meet any of the buyers' preselected rules, notification 
step 1 5 1 2 is skipped and the loan remains published on exchange system 200. The 
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buyer can access the loan information via workstation 280d. In one example, a 
GUI 1804 is provided to the buyer, as shown in FIG. 18. 

GUI 1804 presents information on each loan in the loan pool offered for 
sale to the buyer and allows the buyer to search the loan pool using certain 
criteria. For example, as shown in a GUI 2204 of FIG. 22, the buyer could search 
the loan pool for all loans with a FICO score greater than 639. Those loans 
meeting the selected criteria would be automatically accepted, while ail other 
loans would be declined. The user can also manually accept, decline or suspend 
individual loans in the pool, using pull down arrow 1808 of GUI 1804. In one 
embodiment, the data in GUI 1804 is provided in a Microsoft Excel spreadsheet 
format. In order to decide whether to accept a particular loan, the buyer can also 
review more specific details on each loan in the pool, as shown in a GUI 2 1 04 of 
FIG. 21 

As shown in the lower left of GUI 1 804 there are two tabs 1 8 1 2 and 1 8 1 6. 
The tab 1812, labeled "Detail" displays the information shown in FIG. 18. The 
tab 1816, labeled "Summary" displays the summary information shown in FIG. 
19 in a GUI 1904. 

The summary data is divided into three windows 1908, 1912 and 1916, 
which display information for all accepted, declined and suspended loans from the 
loan pool in FIG. 1 8. This allows the buyer, after performing a search of a loan 
pool, to use the summary information to determine what type of offer to make for 
the remaining, accepted loans from the pool. 

In one embodiment, summary information on a pool can also be displayed 
using graphs, such as bar charts, pie charts, and similar graphs, and stratification 
reports, which are a break down of the data points in a particular category. For 
example, a graph of the distribution of all loans in a pool by FICO score may be 
used to graphically characterize a loan pool. The user will be able to determine 
how many loans in a pool fall within a particular FICO range. A similar graph can 
be generated after the buyer performs a search to show only those loans that meet 
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the search criteria. The summary may also include information such as weighted 
averages of FICO score, loan term, loan rate, combined loan-to-value ratio, and 
debt ratio of the loans in the pool. This information can be generated both before 
and after a buyer performs a search. 

Returning now to FIG. 1 5 A, step 1516 represents when a buyer makes an 
offer for a loan or loan pool. The buyer can enter his offer via workstation 280d. 
Exchange system 200 archives all offers made in database 203a, as shown in a step 
1520. This information is subsequently used to calculate market prices for 
different types of loans, which includes fixed, adjustable, and balloon mortgages 
as well as first-lien (sub-prime, jumbo, conforming) and second-lien (sub-prime, 
home equity, home non-equity, Title I) products. Offers made by a subscriber can 
be canceled at any time before a final agreement is reached. 

The seller who published the loan(s) is then notified by exchange system 
200 that an offer has been made, as shown in a step 1524. Notification can be 
effected to the seller in any of the same manners as discussed above with respect 
to step 1512. Alternatively, the seller may have a personal account in exchange 
system 200 that he periodically checks. Exchange system 200 may notify the 
seller of incoming offers simply by posting the offer to the seller's account. In an 
embodiment, the seller may be able to receive notification in multiple locations, 
and respond to the notification via the same method in which the notification was 
received. For example, if the subscriber receives notification by pager, then the 
subscriber can send a message back on the pager to accept or decline the offer. 

As shown in a decision step 1 528, the seller must then decide whether to 
accept or decline the offer or whether to make a counteroffer. If the offer is 
declined, the flowchart continues in FIG. 1 5B. 

As shown in a step 1 532 of FIG. 15B, exchange system 200 archives the 
declined offer in database 203 a. This information is also used to calculate market 
prices for loans. 



WO 00/39736 



PCT/US99/31107 



-50- 



In a step 1536, exchange system 200 notifies the buyer that his offer has 
been declined, and queries, as shown in a step 1 540, if the buyer has another offer. 
If the buyer does not make another offer, the flow ends at a step 1544. If, 
however, the buyer makes another offer, the flow returns to FIG. 15 A, at step 
1 520, which archives the second offer in exchange system 200, checks to see if the 
loan is still available and notifies the seller of another offer. 

Returning to decision step 1 528, if the seller makes a counteroffer to the 
buyer, the flow continues to FIG. 15C. The seller's counteroffer is archived in 
database 203 a of trading subsystem 210, as shown in a step 1 548. The buyer is 
then notified of the counteroffer as discussed above, as shown in a step 1552. 

The buyer then must decide whether to accept or decline the counteroffer 
or make a second counteroffer, as shown in a decision step 1556. If the buyer 
makes a second counteroffer, exchange system 200 returns to step 1520 in 
FIG. 1 5 A. The buyer f s counteroffer is archived in exchange system 200 and 
continues as described above. 

If the buyer declines the counteroffer exchange system 200 archives the 
declined offer in database 203a, as shown in a step 1560. This information is used 
by exchange system 200 to calculate the market value of loans. In a step 1564, 
exchange system 200 notifies the seller of his declined counteroffer and inquires 
if the seller would like to make another offer, as shown in a step 1568. If no 
further offer is made by the seller, the flow ends at a step 1572. If another offer 
is made by the seller, the flow returns to step 1548 at the top of FIG. 15C. 

Referring back to steps 1528 and 1556, if the seller accepts the original 
offer or the buyer accepts the seller's counteroffer, the flow then continues as 
shown in FIG. 15D. As shown in block 1576, the accepted offer is archived in 
database 203a of trading subsystem 2 1 0. This information is used by exchange 
system 200 to calculate the market prices for loans. Exchange system 200 then 
notifies the buyer or seller, depending on who made the last offer, of the accepted 
offer as discussed above and as shown in a step 1580. 
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In one embodiment, a bid summary is provided, as shown in a GUI 2304 
of FIG. 23. This summary includes the original asking price and detail 
information on the loans in the pool, as shown in a box 2308. Counteroffer 
information is provided in a box 23 12. The status of the bid is displayed in a box 
2316. For example, as shown in FIG. 23, the buyer's counteroffer has been 
accepted. The buyer may then be given the option to withdraw the offer or 
confirm acceptance. 

As shown in FIG. 24, the subscriber may also be provided with a GUI 
2404 that summarizes the subscriber's buying and selling activity. GUI 2404 
shows an example of the subscriber's buying activity. In a box 2408, the pools on 
which the subscriber has bid are shown. Information on the pool, including the 
pool number, date of posting, seller and asking price are displayed. Further, the 
bid information is shown, including the bid price, buyer's name, number of loans 
accepted, declined or suspended, and offer date. Finally, the status of the bid is 
displayed. This provides the subscriber with a summary of the up-to-date status 
of his trading activity. Further, in a box 24 1 2, the subscriber's past trades can be 
summarized. 

Returning now to FIG. 15D, once terms of a trade are agreed upon, 
exchange system 200 checks to see if the buyer has pre-registered with a trust 
company, as shown in a block 1 584. When a buyer typically purchases a loan, the 
sale is contingent upon the buyer conducting a due diligence investigation on the 
loan file or a statistical sampling of loan files, if a pool of loans is purchased. If 
the buyer has not pre-registered with a trust company, then the files are 
transferred to the buyer or the buyer's choice in step 1 586. After the initiation of 
step 1586, the flow ends at a step 1588. However, if the buyer is pre-registered, 
system 200 initiates a transfer of the purchased loan files to the designated trust 
company, as shown in a step 1592. The interaction between system 200 and the 
trust company is discussed in further detail below with reference to FIG. 16. 
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D. Trust (Due Diligence) 

As shown in FIG. 16, system 200 notifies the trust company of incoming 
loan files in a step 1604. This notification can occur in several ways. For 
example, system 200 can notify the trust company via a letter, electronic mail, or 
other notification methods discussed herein. 

System 200 further requests that the seller transfer the loan files directly 
to the trust company, as shown in a step 1608. As such, the buyer does not have 
to oversee this file transfer. This notification can be done simply by sending an 
electronic mail to seller, when the sale is completed, with the name and mailing 
address or electronic mail address of the trust company. 

A hard copy of the loan files may be physically transferred via mail, courier 
or similar means to the trust company for review. In an alternate embodiment, the 
contents of the loan file are scanned and an electronic file containing the scanned 
documents is forwarded to the trust company via an electronic connection. 

Then, independent of system 200, the trust company performs its due 
diligence review of the actual loan file, as shown in a step 1612. The dashed line 
in FIG. 16 represents that this step is being performed at the trust company site, 
outside of system 200. In another embodiment, the seller can transfer a loan file 
to the trust company prior to posting the loan on the exchange system for sale. 
The trust company would perform a due diligence analysis of the loan documents. 
If the loan passed the due diligence inspection, then the seller could mark the loan 
as certified on the exchange system. 

Once the trust company completes its review of the loan files, it notifies 
this buyer whether the loans were certified, as shown in a step 1616. This 
notification is sent to system 200 via workstation 280c and may also be 
communicated directly by the trust company to the buyer. 

If the loans are certified, as shown in a decision step 1620, the trust 
company transfers the loan files to the buyer or directly to the buyer's servicing 
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company or loan file custodian, as shown in a step 1624. In one embodiment, 
system 200 may provide the trust company with notification of where to send the 
certified loan files via workstation 280c. For example, when the trust company 
notified system 200 that the loan files were certified in step 1616, system 200 may 
be programmed to automatically provide information to the trust company on 
where the loan files are to be sent. After this transfer has occurred, this 
interaction ends in a step 1628. 

If the loans are not certified, the loan files are returned by the trust 
company to the seller, as shown in a step 1632 and the interaction ends in a step 
1636. As would be apparent to one skilled in the relevant art, in an alternate 
embodiment, the loan files that are not certified could be forwarded to the seller's 
designee, e.g., loan file custodian. 

E. Servicing 

Once a loan or loan pool has been purchased by a buyer having a pre- 
registered sen/icing company, system 200 initiates a transfer of loan information 
to the servicing company via servicing gateway 250, as shown in a step 1704. 
This process is called "servicing released" in which both the loan(s) and servicing 
rights are sold together. However, in some circumstances, the seller may choose 
to sell the servicing rights to a loan or loan pool separate from the loan. In this 
case, referred to as "servicing retained", the selling of the servicing rights to a 
loan or loan pool would be handled by system 200 in the same manner as 
discussed in FIGS. 15A-15D with respect to sales of loans. As such, the seller 
would publish the servicing rights to the loan or loan pool for sale, as shown in 
step 1 506. The process for selling the servicing rights separately would continue 
as with the posting and selling of a loan. Thus, for example, in step 1704, 
exchange system 200 would transfer the information to the servicing company that 
purchased the servicing rights of a loan or loan pool. 
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Returning to FIG. 17, the servicing company uses loan information 
provided by system 200 to send out coupon booklets or monthly invoices, as 
shown in a step 1708. The servicing company then monitors the borrowers 
monthly payments and archives history payment information. For example, the 
servicing company will store information indicating whether the borrower made 
a monthly payment on time. 

If a payment is overdue, as shown in a decision step 1712, the servicing 
company decides what action is required, in a step 1716, such as filing a claim in 
bankruptcy, or filing a claim in court for overdue payments. Often, the servicing 
company will place several calls to the borrower to resolve any overdue payments 
before filing claims. 

The servicing company can access system 200 via workstation 280h to 
periodically forward this payment history information back to the system 200 as 
shown in a step 1720. In particular, the servicing company sends servicing 
information back to system 200 via servicing gateway 250 to update the system. 
In one embodiment, this updating occurs nightly, however, it would be apparent 
to one skilled in the relevant art(s), that such updates could occur more or less 
frequently, as desired. 

Many servicing companies employ mortgage service software such as the 
Mortgage Servicer Systems software available from Financial Industry Computer 
Systems (FICS) Group of Brussels, Belgium, The invention interfaces with such 
software to facilitate upload and download information from servicing gateway 
250 to and from system 200. 

F. Securitization 

As shown by a block 320 in FIG. 3, the investors can access system 200 
via workstation 280e look for loan pools for sale by mortgage bankers to 
purchase. Using trading subsystem 210, investors can make bids on loan pools 
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for sale on the system 200. The investors then use collections of these purchased 
loan pools to create mortgage-backed securities, as discussed in detail above. The 
investors can publish these mortgage-backed securities on system 200 via 
workstation 280e for sale to interested buyers. 

6 Brokerage 

As explained above, brokerage firms may be employed by the investors to 
find buyers for the mortgage-backed securities. As shown by a block 324 in FIG. 
3, these brokerage firms can access system 200 via workstation 280g to find out 
risk-return statistical information about the loans in the loan pool, that is being 
used to back the mortgage-backed security. Further, the brokerage firms can 
access information from system 200 via the workstation 280h to find out payment 
history information for the loans in the loan pool. 

H. Credit Rating 

As shown by a block 336 in FIG. 3, a credit rating agency, typically hired 
by the brokerage firm to rate a mortgage-backed security, can access system 200 
to review the payment history and risk-return information in system 200 in order 
to rate a particular security. For example, the credit rating agency can review the 
payment history of the loans used to back a particular mortgage-backed security, 
to determine whether the loans are likely to be prepaid or go into default. 

/. Risk/Return 

A risk-return module, represented by risk-return interface 332 in FIG. 3, 
is accessed via workstation 280g and is meant to provide the subscriber with 
quality control and risk analysis data as they use the exchange system 200 in their 



WO 00/39736 




PCT/US99/31107 



decision-making processes. In one embodiment, the risk-return module includes, 
for example, one or more of the following calculations typically known and used 
by one skilled in the relevant art to make a determination of risk associated with 
a particular loan or loan pool: prepayment calculations on a loan or loan pool, 
duration calculations on a loan or loan pool, convexity (y distribution), vega, 
derivative with respect to total prepayment, housing turnover, refinancing, 
conditional prepayment rate (CPR), option adjusted spread (OAS), value at risk 
(VAR), cash flow, total rate of return, price/yield calculations, and scenario 
builders for cash flow analysis. 

In one embodiment, the risk return module further includes an index of 
trade data from live transactions or trades that occur over the exchange system 
200. This trade data may include, for example, volume of trades, weighted 
average coupon, average combined loan-to-value ratio, average FICO score, 
average term of loan, average rate and average debt ratio. 

The risk return module may also incorporate other data points from 
externally running subsystems such as, but not limited to, the loan origination 
subsystem 240 and servicing subsystem 250. The risk-return module is designed 
to be very flexible in nature. This means that all processes read initialization files 
(*.ini) upon starting to set parameters. Command line arguments and GUI 
methods of setting variables during execution are also important functions. 

The data contained in the risk-return module is important because it is 
shared across many different subsystems within exchange system 200. As outlined 
below, reports and visualizations, such as graphs, of data in the risk return module 
are provided for the subscribers. Through operation of the system 200 over time, 
the data in the risk return module allows for predictive modeling. The purpose of 
the risk return module is to use collect the data over time to build dependence 
from subscribers on the system 200 so that full trade-based decisions can be made 
based on the data available to the users in the risk return module, similar to data 
relied on by individuals involved in transactions on Wall Street today. 
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Neural-network technology can be used in the risk-return module. The 
network will train off of real-time trades that are occurring in trading subsystem 
210 within the exchange system 200. The data in the risk-return module evolves 
over operation time of the system 200. Thus, as will be apparent to one skilled 
in the relevant art(s), necessary measures within the risk-return module must be 
taken in order to protect and secure the data used within it. 

There is also statistical and scientific analyses conducted within the risk- 
return module. The results of these analyses are presented to the user in the form 
of graphs and other visualizations of the data. These graphs and other 
visualizations are more easily used by the subscribers than massive numerical 
reports. Massive reports can also be provided, however, to illustrate those details 
of the calculations that may not be readily apparent from the visualizations of the 
data. 

In one embodiment of the invention, the risk-return module provides a 
graph similar to a NAV-type graph that is time focused, such that it correlates 
time with some value that changes over time. In the invention, this variable is 
often focused around money (e.g., volume of trades, value of trades, etc.). While 
time will be on one axis, the other axis will contain sellers or buyers. As such, a 
subscriber will be able to peruse (at-a-glance) what other companies within the 
exchange system 200 are doing. 

In an embodiment of the invention, an index of the risk return module 
includes graphs of the following information: (1 ) single company number of trades 
over time; (2) multiple company number of trades over time; (3) volume of trades 
on the trading system over time; (4) total number of bids and sells over time; and 
(5) changes in company criteria over time. The preceding listing of graphs is 
provided by way of example only. It would be apparent to one skilled in the 
relevant art(s) that graphs depicting the change over time of other types of data 
may be useful as a predictor of risk. 
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In one embodiment, access to the risk-return module is provided over a 
secure public-key cryptosystem web connection {e.g., SSL). As such, the risk 
return module functions are limited to a service-based environment along with the 
actual trading platform (/. e. , subsystem 2 1 0). This configuration allows for quick 
updates, and immediate updating with new functionalities. This is particularly 
important to the exchange service provider organization because it may test 
different prediction algorithms and the like, as they are discovered/developed, and 
the ability to swap and make new algorithm outputs available to subscribers in 
short order is needed. 

The risk-return module interfaces with the following subsystems (as 
described in FIG, 2 above), each with their own unique data repository: loan 
origination subsystem 240, trading subsystem 210, portfolio subsystem 220, and 
boarding relay server 225 conduit. Boarding relay server 225 conduit is a secure 
transport and relay mechanism that exists at the exchange system 200. The data 
that is piped through boarding relay server 225 conduit will be archived and usable 
by analyses processes of the risk return module. In one embodiment, this conduit 
is based in part on the open extensible Markup Language (XML) specification 
maintained by the World Wide Web Consortium (W3C), whereby many other 
potential processes are able to read these files during integration with one of the 
several (freeware) publicly available XML/DTD parsers. 

In one embodiment, the risk-return module collects and presents data on 
the valuation of the Treasury Bill (T-Bill) from Wall Street. As more trades occur 
over the system 200, and more subscribers use the system 200, the data in the risk 
return module becomes an even more valuable predictor of risk. 

The invention also may include a "ticker-tape" visualization of certain data 
in the risk return module. "Splash" or message screens can be utilized in the 
beginning of the exchange system 200 operation {i.e., as the data repositories are 
ramping up). These presentation formats can be used to highlight a certain subset 
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of data points in real-time. Examples of such data include mean trade value, total 
volume of trades, etc. 

The data within the risk-return module will be in a number of file formats, 
including, for example: flat file (XML), Relational Database Systems (RDBMS), 
and Object Database Systems (ODBMS). The system utilizes "adapters" to these 
different data repositories, and reuses them across all data repositories of that 
type. 

VII. Environment 

The invention (i.e., exchange system 200 or any part thereof) may be 
implemented using hardware, software or a combination thereof and may be 
implemented in a computer system or other processing system. In fact, in one 
embodiment, the invention is directed toward one or more computer systems 
capable of carrying out the functionality described herein. An example of a 
computer system 2000 is shown in FIG. 20. The computer system 2000 includes 
one or more processors, such as processor 2004. The processor 2004 is 
connected to a communication infrastructure 2006 (e.g., a communications bus, 
cross-over bar, or network). Various software embodiments are described in 
terms of this exemplary computer system. After reading this description, it will 
become apparent to a person skilled in the relevant art(s) how to implement the 
invention using other computer systems and/or computer architectures. 

Computer system 2000 can include a display interface 2005 that forwards 
graphics, text, and other data from the communication infrastructure 2002 (or 
from a frame buffer not shown) for display on the display unit 2030. 

Computer system 2000 also includes a main memory 2008, preferably 
random access memory (RAM), and may also include a secondary memory 2010. 
The secondary memory 2010 may include, for example, a hard disk drive 2012 
and/or a removable storage drive 2014, representing a floppy disk drive, a 
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magnetic tape drive, an optical disk drive, etc. The removable storage drive 2014 
reads from and/or writes to a removable storage unit 2018 in a well-known 
manner. Removable storage unit 2018, represents a floppy disk, magnetic tape, 
optical disk, etc. which is read by and written to by removable storage drive 2014. 
As will be appreciated, the removable storage unit 20 1 8 includes a computer 
usable storage medium having stored therein computer software and/or data. 

In alternative embodiments, secondary memory 2010 may include other 
similar means for allowing computer programs or other instructions to be loaded 
into computer system 2000. Such means may include, for example, a removable 
storage unit 2022 and an interface 2020. Examples of such may include a 
program cartridge and cartridge interface (such as that found in video game 
devices), a removable memory chip (such as an EPROM, or PROM) and 
associated socket, and other removable storage units 2022 and interfaces 2020 
which allow software and data to be transferred from the removable storage unit 
2022 to computer system 2000. 

Computer system 2000 may also include a communications interface 2024 . 
Communications interface 2024 allows software and data to be transferred 
between computer system 2000 and external devices. Examples of 
communications interface 2024 may include a modem, a network interface (such 
as an Ethernet card), a communications port, a PCMCIA slot and card, etc. 
Software and data transferred via communications interface 2024 are in the form 
of signals 2028 which may be electronic, electromagnetic, optical or other signals 
capable of being received by communications interface 2024. These signals 2028 
are provided to communications interface 2024 via a communications path (i.e., 
channel) 2026. This channel 2026 carries signals 2028 and may be implemented 
using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link and 
other communications channels. 

In this document, the terms "computer program medium'* and "computer 
usable medium" are used to generally refer to media such as removable storage 
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drive 2014, a hard disk installed in hard disk drive 2012, and signals 2028. These 
computer program products are means for providing software to computer system 
2000. The invention is directed to such computer program products. 

Computer programs (also called computer control logic) are stored in main 
5 memory 2008 and/or secondary memory 20 1 0. Computer programs may also be 

received via communications interface 2024. Such computer programs, when 
executed, enable the computer system 2000 to perform the features of the 
invention as discussed herein. In particular, the computer programs, when 
executed, enable the processor 2004 to perform the features of the invention. 
10 Accordingly, such computer programs represent controllers of the computer 

system 2000. 

In an embodiment where the invention is implemented using software, the 

software may be stored in a computer program product and loaded into computer 

system 2000 using removable storage drive 2014, hard drive 2012 or 
15 communications interface 2024. The control logic (software), when executed by 

the processor 2004, causes the processor 2004 to perform the functions of the 

invention as described herein. 

In another embodiment, the invention is implemented primarily in 

hardware using, for example, hardware components such as application specific 
20 integrated circuits (ASICs). Implementation of the hardware state machine so as 

to perform the functions described herein will be apparent to persons skilled in the 

relevant art(s). 

In yet another embodiment, the invention is implemented using a 
combination of both hardware and software. 



25 



WO 00/39736 




PCT/US99/31107 



VIII. Data Transformation and Mapping Process 

The Data Transformation and Mapping (DTM) process is a method used 
by exchange systems 200 and 2700 to simplify the transfer of data between the 
exchange system and subscribers' computer systems. The DTM process allows 
loan information to be standardized into an extensible Markup Language (XML) 
processing format which is a standard maintained by the World Wide Web 
Consortium (W3C). Before transferring data information back to the user, the 
DTM process can be used to translate the XML format into a user's predefined 
format when different from the XML standard. This DTM process eliminates the 
need for subscribers to create customized adaptations between different subscriber 
systems. For example, the seller no longer needs any proprietary communications 
expenditures to do proprietary business with a particular buyer. At the same time, 
the buyer's receipt of loans from many sellers is simplified and streamlined. 

FIG. 25 is a flow diagram illustrating the DTM process and the data flow 
and formatting between exchange system 2700 and the subscriber. FIG. 25, as 
illustrated, is an example of flow trading where the exchange system 2700 
ftmctions as a correspondent delivery system. 

As shown in FIG. 25, a correspondent subscriber uploads loan data into 
system 2700 in step 2502. 

In a step 2504, before the loan data that was input by the correspondent 
subscriber is forwarded to exchange system 2700, the data undergoes a 
transformation using the DTM process to ensure that the data is in the correct, 
standardized processing format for the exchange system. In this transformation, 
the DTM process takes the individual pieces of loan data and ensures that the 
position and formatting of the information is in a standardized form. This 
processing includes the application of a preliminary, standard rules based filter, as 
discussed further below. For example, in the marketplace, there may be subtle 
differences in the way that the appraisal value of a property is determined. The 



WO 00/39736 




PCTAJS99/31107 



DTM process is able to compensate for these differences and standardize loan 
data entries into a single format, such as XML. 

In FIG. 26, the DTM process is illustrated where X, Y, and Z represent 
various pieces of loan information. For example, assume X=LTV, Y=Social 
Security Number (entered with dashes), and Z= FICO. For entry into exchange 
system 2700, it may be necessary to have the X and Z values in a different 
position, and the Y value displayed without dashes. The DTM" process would 
transform the data in the standardized form as shown in the XML column of FIG. 
26. After the loan information has been processed in exchange system 2700, the 
DTM process sends the data to the Buyer in the XML-format or in the Buyer's 
predefined format, if preferred by the Buyer. 

Returning to FIG. 25, in a step 2506, the XML-formatted data is received 
and processed by exchange system 2700. 

In a step 2508, the processed loan data is again translated using the DTM 
process into a pre-defined format for a particular buyer, if different from the 
standard XML format. 

In a step 2510, a Rules Based Filter (RBF) is applied to the translated 
data. The RBF is made up of 2 components: (1) a standard and (2) customized 
filter. The standard filter component comprises basic logic checks and rules which 
are established by the exchange system 200. For example, the system may need 
to determine whether the interest rate been entered with two decimal places. The 
customized filter component is comprised of user-defined rules or criteria. 

In step 2512, the processed and re-formatted (if necessary) loan data is 
transferred to the buyer. The loan data can then be processed by the buyer using 
its proprietary backoffice system. 

This DTM process and the CDS platform, discussed above with reference 
to FIG. 28, have several advantages. First, the system shortens the acquisition 
cycle as data is immediately available for review by a buyer allowing for 
streamlined processing and faster funding. Second, the system ensures that the 
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transferred data meets the data requirements of the buyer's backoffice systems. 
Third, the system can automatically validate submitted loan data against the 
buyer's own defined purchase criteria to ensure that the loans submitted to the 
buyer meet the buyer's product guidelines prior to delivery. Fourth, the system 
reduces costs of maintenance and training required at the buyer and seller. Fifth, 
the system provides reporting and monitoring to track loan volume and quality, 
thereby improving correspondent management. 

The open platform, discussed above with reference to FIG. 28, also has 
several advantages. For example, the system allows buyers to expand market 
share and increase loan acquisition opportunities through development of 
relationships with new sellers. The system also allows sellers to enhance exit 
strategies for those loans which they have acquired and want to sell. 

IX Subscriber Tools 

Various subscriber tools may be provided to the subscriber as 
enhancements of the present invention. For example, a work flow manager tool 
may be provided that allows a subscriber to assign, set up, and track tasks that 
need to be accomplished in, for example, settlement on the sale of a loan. The 
work flow manager tool may also allow the subscriber to notify each party of the 
assigned tasks. 

Another tool that may be provided to the subscriber is a specialized 
calculator that allows the subscriber to calculate statistical information on a loan 
or set of loans selected by the subscriber. 

Further, a reporting and data mining tool may be provided to enable 
subscribers to evaluate market data and decide on which loans to make a bid. 

A comparison tool allows a subscriber to compare program matrices of 
various buyers to determine the best price the subscriber may be able to obtain for 
a loan or loan pool. 
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X Value Added Services 

The present invention may include links to several value added services 
that can be used by the subscriber to facilitate buying or selling a loan. These 
value added services include, for example, automated underwriting, automated 
pricing, rate locking, loan product comparison mapping, credit scoring, credit 
updates, CRA qualification and appraisal updates. 

A. Automated Underwriting 

Many companies in the business of purchasing loans use an automated 
underwriting engine which makes decisions on whether to purchase a loan based 
on predetermined underwriting guidelines. Examples of such decision support 
engines include, Good Decisions™, a product of GE Capital Mortgage Services, 
Inc. and Asset Wise™, a product RFC Mortgage Services Ltd. In use, the system 
allows subscribers to select certain loans of interest to check against the decision 
support engine. Once the loans have been selected, the subscriber clicks or selects 
a decision support service option on the user interface. A query is then 
automatically sent to a decision engine resident on the system of the present 
invention or located on another Web site. The decision engine checks the 
information for the selected loans against the automated underwriting criteria and 
renders a decision to the subscriber on whether to purchase the loan. In another 
embodiment, the subscriber would be able to choose from among a variety of 
proprietary automated underwriting systems available through links on the 
exchange system Web site, or the subscriber could select his company's own 
proprietary automated underwriting engine. 
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B. Automated Pricing 

Similar to the automated underwriting service, the present invention may 
also provide a value added pricing service to subscribers. This pricing service 
would automatically calculate the price for a particular loan based the loan data. 
This service would be helpful to subscribers selling a loan, who are not sure how 
to price the loan that they wish to post on the system. This service would also be 
helpful to subscribers interested in buying a loan, who are not sure how much to 
offer for the loan. 

In use, the system allows subscribers to select certain loans of interest to 
send to the pricing service. Once the loans have been selected, the subscriber 
clicks or selects a pricing service option on the user interface. A query is then 
automatically sent to a pricing engine, either resident on the system of the present 
invention or linked to another Web site. The pricing engine passes the loan data 
through a pricing algorithm in order to render a suggested price to the subscriber 
for each selected loan. Similarly, the pricing service could be used to provide a 
suggested price on a pool of loans. 

C Rate Locking 

The present invention may also provide a rate locking service. In this 
service, a subscriber can send a loan to a prospective buyer for sale. If the buyer 
makes an offer to purchase the loan, the rate locking service will allow the 
subscriber to accept this offer and lock the price on the system. 

Z). Loan Product Comparison Mapping 

The present invention may also provide a loan product comparison 
mapping service. In this service, a subscriber can compare two different loan 
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products by comparing each loan product to the subscriber's program matrix. In 
this way, each loan product is mapped against the subscriber's matrix so that the 
subscriber can more easily compare the different loan products to each other. 

K Credit Scoring/Credit Updates 

The present invention may also provide a credit scoring/credit update 
service. In this service, subscribers can select certain loans of interest. Once the 
loans have been selected, the subscriber clicks or selects a credit update option on 
the user interface. A query is then sent a credit service bureau containing up-to- 
date credit scoring information. This information is then provided, via the system 
of the present invention, to the subscriber for each of the borrowers on the 
selected loans. This service may be used before a loan is closed to check the 
credit score of the loan applicant(s) or it may be used before buying or selling a 
closed loan to check and update the credit score information for the borrower(s). 

E CRA Qualification 

In the case of the value added service for CRA qualification, a link may be 
provided to allow the subscriber to check to see how many loans in a particular 
pool are CRA qualifying. 

The Community Reinvestment Act (CRA) is a federal regulation which 
was designed to encourage depository institutions to help meet the credit needs 
of the communities in which they operate, including low and moderate income 
neighborhoods. The Act requires that a certain number of loans which meet CRA 
criteria be acquired each year. The criteria used to determine possible CRA 
compliance includes: (1) whether the applicant has low or moderate income and 
the property is within a certain census tract; (2) whether the applicant has low or 
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moderate income only; (3) whether the piece of property is on a particular census 
tract; and (4) whether neither (l)-(3) are met. 

In response to the subscribers' need to comply with the CRA, the present 
invention may flag those loans which would allow the subscriber to fulfill part of 
their CRA purchase obligations. An independent, third party may be used by the 
exchange system to verify that the listed loan has met the federal guidelines and 
is indeed CRA compliant. The advantage to flagging CRA qualified loans is that 
it provides a centralized and quick tool for institutions to sell or buy these types 
of loans. 

In one embodiment, the system marks or flags the loans appearing on the 
system as CRA qualified, if applicable. In another embodiment, the system allows 
subscribers to select certain loans of interest to check for CRA qualification. 
Once the loans have been selected, the subscriber clicks or selects a CRA option 
on the user interface. The query is then automatically sent to a CRA engine, 
either resident on the system of the present invention or linked on another Web 
site, which checks the CRA qualifications for the selected loans and returns a 
response to the subscriber on the status of each loan. 

G. Appraisal Updates 

Another value added service that may be provided to subscribers on the 
present invention is an appraisal service. In this service, subscribers can select 
certain loans of interest. Once the loans have been selected, the subscriber clicks 
or selects an appraisal option on the user interface. A query is then sent to an 
appraisal engine and/or database, either resident on the system of the present 
invention or linked on another Web site, which contains recent appraisal 
information. Updated appraisal information is then provided to the subscriber for 
each of the selected loan properties. This service is particularly useful for trading 
of "seasoned" loans, i.e., loans that were made several years ago such that the 
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value of the underlying property may have changed since the original appraisal 
date at the time of closing. 

XI. Conclusion 

5 

While various embodiments of the invention have been described above, 
it should be understood that they have been presented by way of example, and not 
limitation. It will be apparent to persons skilled in the relevant art(s) that various 
changes in form and detail may be made therein without departing from the spirit 
10 and scope of the invention. This is especially true in light of technology and terms 

within the relevant art(s) that may be later developed. Thus the invention should 
not be limited by any of the above-described exemplary embodiments, but should 
be defined only in accordance with the following claims and their equivalents. 
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What Is Claimed Is: 



1. 



A system for exchanging data used in trading financial products in the 



secondary market, comprising: 

means for receiving data, including loan information, for trading 
of a loan(s) from a first subscriber in a first data format; 

means for translating said data into an exchange system default 

format; 

means for applying user-defined filter(s) to said data; 
means for sending said data from the system to a second subscriber 
in a format selected by said second subscriber. 

2. The system of claim ], wherein said first subscriber is selected from the 
group consisting of at least one of the following: a broker, a mortgage 
bank correspondent, a servicing company, and a mortgage bank investor. 

3. The system of claim 1 7 further comprising: 

means for applying a Rule Based Filter (RBF) to said data to 
perform basic logic checks. 

4. The system of claim ] , wherein said exchange system default format is an 
XML format. 



5. 



The system of claim 1, further comprising: 

means for flagging said loan information which 
Community Reinvestment Act (CRA) qualifying mortgages. 



contains 
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6. The system of claim 1, further comprising: 

means for enabling the user to select fee calculations automatically. 

7. The system of claim 1, further comprising: 

means for generating transaction logs of account and trading activity. 

8. The system of claim 1 , further comprising: 

means for sending the loan information to a decision engine to 
perform automated underwriting. 

9. The system of claim 1, further comprising: 

means for sending the loan information to a pricing engine to 
perform automated pricing. 

10. The system of claim 1, further comprising: 

means for sending at least a portion of the loan information to a 
credit update service. 

1 1 . The system of claim 1 , further comprising: 

means for sending at least a portion of the loan information to an 
appraisal update service. 

12. The system of claim 1, further comprising: 

means for sending loan documents to a trust company to perform 
a due diligence analysis on the loan documents to certify said loan 
information before said loan information is sent to said second subscriber. 
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13. A method for exchanging data used in trading financial products in the 
secondary market, comprising the steps of: 

(a) receiving data, including loan information, for trading of a loan(s) 
from a first subscriber in a first data format; 

(b) translating said data into an exchange system default format; 

(c) applying user-defined filters) to said data; and 

(d) sending said data from the system to a second subscriber in a 
format selected by said second subscriber. 

14. The method of claim 13, wherein said first subscriber is selected from the 
group consisting of at least one of the following: a broker, a mortgage 
bank correspondent, a servicing company, and a mortgage bank investor. 

15. The method of claim 13, further comprising the step of: 

(e) applying a Rule Based Filter (RBF) to said data to perform basic 
logic checks. 

16. The method of claim 13, wherein said exchange system default format is 
an XML format. 

17. The method of claim 13, further comprising the step of: 

(e) flagging said loan information which contains Community 
Reinvestment Act (CRA) qualifying mortgages. 

18. The method of claim 13, further comprising the step of: 

(e) allowing a subscriber to select fee calculations automatically. 
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19. The method of claim 13, further comprising the step of: 

(e) generating transaction logs of account and trading activity. 

20. The method of claim 13, further comprising the step of: 

(e) sending the loan information to a decision engine to perform 
automated underwriting. 

2 1 . The method of claim 13, further comprising the step of: 

(e) sending the loan information to a pricing engine to perform 
automated pricing. 

22. The method of claim 13, further comprising the step of: 

(e) sending at least a portion of the loan information to a credit update 
service. 

23. The method of claim 13, further comprising the step of: 

(e) sending at least a portion of the loan information to an appraisal 
update service. 

24. A computer program product comprising: 

control logic stored therein for causing a computer to allow the 
exchange of data used in trading financial products in the secondary 
market, said control logic comprising: 

first computer readable program code means for receiving data for 
trading of a loan(s) from a first subscriber in a first data format; 

second computer readable program code means for translating said 
data into an exchange system default format; 

third computer readable program code means for applying user- 
defined filters) to said data; and 
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fourth computer readable program code means for sending said 
data from the system to a second subscriber in a format selected by said 
second subscriber. 

25. A program storage device readable by a machine, tangibly embodying a 
program of instructions executable by the machine to perform method step 
of enabling trading of a loan(s) via a network site, said method steps 
comprising: 

(a) receiving data, including loan information, for trading of a loan(s) 
from a first subscriber in a first data format; 

(b) translating said data into an exchange system default format; 

(c) applying user-defined filter(s) to said data; and 

(d) sending said data from the network site to a second subscriber in 
a format selected by said second subscriber. 

26. A centralized system for trading financial products in the secondary 
market, wherein the system is capable of being accessed by a plurality of 
subscribers, the system comprising: 

means for receiving loan information for a plurality of loans in a 
loan pool from a first subscriber, and 

means for receiving selection inputs from a second subscriber in 
order to make an acceptance determination regarding each of said loans 
in said loan pool, whereby said system allows trading of loans in the 
secondary market. 

27. The system of claim 26, wherein said first subscriber is selected from the 
group consisting of at least one of the following: a borrower a broker, a 
mortgage bank correspondent, a servicing company, and a mortgage bank 
investor. 
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28. The system of claim 26, further comprising: 

means for receiving selection inputs from said first subscriber in 
order to create said loan pool. 

29. The system of claim 28, wherein said means for receiving selection inputs 
from said first subscriber, comprises: 

means for searching said loan information using loan criteria; and 
means for selecting individual loans to include in said loan pool 
based on said loan information. 

30. The system of claim 26, wherein said means for receiving selection inputs 
from said second subscriber comprises: 

means for reviewing loan information for each loan in said loan 

pool; 

means for individually accepting, declining or suspending each loan 
in said loan pool; and 

means for extending an offer on those loans in said loan pool that 
are accepted. 

3 1 . The system of claim 30, wherein said means for receiving selection inputs 
from said second subscriber further comprises: 

means for notifying said first subscriber associated with said loan 
pool of said offer. 



32. 



The system of claim 30, wherein said reviewing means comprises: 

means for searching said loan information for each loan in said loan 
pool based on loan criteria. 
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33 . The system of claim 32, wherein said loan criteria is selected from a group 
consisting of at least one of the following: FICO score, combined loan-to- 
value ratio, income-to-debt ratio, interest rate, loan amount, term of loan, 
appraisal value of property, monthly income of borrower, type of loan, 
points, purchase balance, original balance, and state. 

34. The system of claim 26, further comprising: 

means for registering at least one rule corresponding to a 
subscriber's purchasing criteria. 

35. The system of claim 34, further comprising: 

means for reviewing said rule(s) to use in forming said loan pool. 

36. The system of claim 34, further comprising: 

means for matching said rule(s) to said loan information; and 
means for notifying said subscriber when said loan information for 
one or more of said loans matches said subscriber's rule(s). 

37. The system of claim 36, wherein said notifying means notifies said 
subscriber by at least one of the following devices: pager, electronic mail, 
cellular telephone, personal digital assistant, and telephone. 

38. The system of claim 26, further comprising: 

means for collecting and analyzing trade data to create an index. 

39. The system of claim 38, wherein said trade data are selected from the 
group consisting of at least one of the following: volume of trades, 
weighted average coupon, average combined loan-to-value ratio, average 
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FICO score, average term of loan, average rate, and average debt ratio. 

40. The system of claim 38, wherein said index is used to develop a 
subscriber's rule(s). 

41 . The system of claim 26, further comprising: 

means for forwarding loan information for a loan to a servicing 
company to service said loan. 

42. The system of claim 26, further comprising: 

means for trading in a mortgage-backed security that is backed by 
at least one loan pool. 

43 . A method for trading financial products in the secondary market on a 
network, wherein the network is capable of being accessed by a plurality 
of subscribers, the method comprising the steps of: 

(a) receiving loan information for a plurality of loans in a loan pool 
from a first subscriber; and 

(b) receiving selection inputs from a second subscriber in order to 
make an acceptance determination regarding each of said loans in 
said loan pool, whereby the method allows trading of loans in the 
secondary market. 

44. The method of claim 43, further comprising the step of: 

(c) receiving selection inputs from said first subscriber in order to 
create said loan pool 
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45. A computer program product comprising: 

control logic stored therein for causing a computer to allow trading 
financial products in the secondary market, wherein a plurality of subscribers use 
said computer program product, said control logic comprising: 

first computer readable program code means for receiving loan 

information for a plurality of loans in a loan pool from a first subscriber; 

and 

second computer readable program code means for receiving 
selection inputs from a second subscriber in order to make an acceptance 
determination regarding each of said loans in said loan pool, whereby said 
system allows trading of loans in the secondary market. 

46. A program storage device readable by a machine, tangibly embodying a 
program of instructions executable by the machine to perform method 
steps of enabling trading of a loan pool via a network site, said method 
steps comprising: 

(a) receiving loan information for a plurality of loans in a loan pool 
from a first subscriber; and 

(b) receiving selection inputs from a second subscriber in order to 
make an acceptance determination regarding each of said loans in 
said loan pool, whereby the method allows trading of loans in the 
secondary market. 

47. A computer program product comprising: 

control logic stored therein for causing a computer to allow pooling of 
loans, wherein a plurality of subscribers use said computer program product, said 
control logic comprising: 

first computer readable program code means for receiving loan 

information; 
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second computer readable program code means for searching said 
loan information based on loan criteria; and 

third computer readable program code means for selecting loans 
based on said loan information to include in a loan pool 

48. A computer program product comprising: 

control logic stored therein for causing a computer to develop an index, 
said control logic comprising: 

first computer readable program code means for receiving trade 
data for a plurality of loans; and 

second computer readable program code means for analyzing said 
trade data to create an index. 
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Seller Data 




Pricing: 


1053% 


Price: 


3.945398 



Summary Oata 
Accepted Loans 



Declined Loans 



Suspended Loans 



Number of Loans: 

Par Value (5): 

WAC: 

WA FICO: 

WA CLTV: 

WA DR: 



. 91 
3.739.903 
12.8 
6893 
117.7 
40.0 



Number of Loans: 
Par Value ($): 
WAC: 
WA FICO: 
WA CLTV: 
WA DR: 



0 
0 
0.0 
0.0 
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Number or Loans: 
Par Value ($): 
WAC: 
WA HCO: 
WA CLTV: 
WA DR: 
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0.0 
0.0 
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